[TRACKING] Battery flipping between charging and discharging / Draws from battery even on AC

I would wonder if the problem has to do with the problem where there was a component overheating causing the left side ports to go totally inop.

I have no idea. I am a pure layman here and will just leave it to those who can troubleshoot better than I.

Fwiw, when I tried this a while ago, I could reproduce the problem with all four ports, even with the modules removed. (Support had asked me to try this, thatā€™s why I did some more tested.)

Please help me
If you are able to solve this problem ? I HAVE SAME PROBLEM battery is not charging now my laptop is dead ,it was keeping flipping btw charging and discharging, i have hp 12 gen laptop and had a kali linux base os

You should probably contact HP. Please donā€™t contact Framework support over this because they only support Framework laptops.

1 Like

Just upgraded to the latest BIOS 3.05 and this is still happening, when the limit is set at 80% it flips between charging and discharging it never says charged. It does seem less of a problem when the limit is set to 100% though, it seems to switch to discharging when put under stress then after a few seconds goes back to fully-charged.

1 Like

Dear Developer

It has been some more months now, and the problem persists. (On my 2034 AMD F-13, running Linux, and BIOS 3.05, intermittently the machine briefly discharges when connected to AC. I am using a Framework charger.) This thread suggests that quite a few people are affected. So: any progress, please?

2 Likes

For AMD, how about using Smokeless UMAF and select AMD_PBS Hidden > EC/PD Configurations, Enable Charger mode BYPASS

Thanks for the pointer and for the screenshot and the information but, no. For, Iā€™m not at the stage where Iā€™m going to flash my BIOS with something third-party, where that third-party BIOS has ā€˜use at your own riskā€™ written all over it in big letters.

You arenā€™t flashing it you are just booting it temporarily but the ā€œuse at your own riskā€ bit stays of course

1 Like

Sad to see that this is a problem on AMD too. I was hoping that the AMD models are not affected.

@Matt_Hartley

Any progress on this issue, please? (The issue is this: when a Framework laptop is connected to a charger, the computer continues to draw power intermittently from the battery or at least to indicate that it is so doing.)

Do you still need people to come up with reproducible cases, using Fedora or Ubuntu, and send them to support? If so, please give (or link from above) the exact way that one should try to reproduce (and record) the problem.

Look at the nonsense that I have had to implement on my AMD F-13 in order to workaround this bug.

I have a Bash script that at boot sets brightness according to power status. The script now contains this:

 local stateToSet='battery'
 [. . .]
 case ${pwr_pc} in
    "${pwr_pc_name[F13]}")
        case ${F13_workaroundPowerBug} in
        true)
            local -i count=0
            local -ir limit=3
            while [[ $(/usr/bin/acpi) == *'Discharging'* ]]; do
                ${pwr_dbg} && dbg_log "F13 detected as discharging: #${count}."
                sleep 5
                ((count++))
                [[ ${count} -ge ${limit} ]] && break
            done
            [[ ${count} -lt ${limit} ]] && stateToSet='ac'
            ;;
        *)
            [[ $(/usr/bin/acpi) == *'Battery 1: Discharging'* ]] || stateToSet='ac'
            ;;
        esac
        ;;
    *)
        [[ $(/usr/bin/acpi -a) == *'on-line' ]] && stateToSet='ac'
        ;;
    esac

It is a blessing and something of a surprise that the program tlp is not affected: at boot it seems to detect the power status correctly somehow (though the bug makes it somewhat unclear even what it is for the status to be correct here!)

EDIT: unlike some others who have commented within this thread, I have not tried the ostensible fix that is the ā€˜Smokeless_UMAFā€™ thingy.

EDIT: I fixed an errors within the script. One of those errors was not coping with the fact that my Framework laptop gives data for two batteries, even though only one is installed and, to my knowledge, installable. What is going on there?

I changed it to ENABLE, and nothing happened. Charging wattage(using a USB meter) with 60W, 100W or 20W look almost exactly(at least I canā€™t tell the difference) the same.
Setting the battery charge limit lower when the battery level is higher still discharges the battery while the USB current 0.01A(no power directly from USB). i.e this so-called BYPASS setting does nothing

Any progress here?

I had it mostly fixed by extremely underclocking the CPU via TLP, but I ran into the ā€œ400MHz frequencyā€ bug the other day I had to reset and change some TLP settings, and now I get the flip-flopping charging status no matter what CPU settings I use.

I canā€™t really believe Framework support here, that they canā€™t reproduce this problem. I have two FW13 and both have this behavior.

Here we have a screenshot of my monitoring system that shows that on CPU boost spikes the power system draws a little power from the battery instead of completely relying on the charger (Ignore the 90% status here. Itā€™s set 90% max charge here, but same behavior on 100% max).

Also, as previously stated, this happens on 3rd party chargers (Ugreen 100W in my case) as well as FW chargers.

To FW Support on how to reproduce this: Use the laptop. Literally doing anything. But loading a heavy website like YT will definitely trigger it.

1 Like

Iā€™ve now monitored the wattage and charging status with the following script.
All run with an FW13 power adapter and a 2m ugreen usbc cable (same problem happens with the original cable), using the top right usbc port on an intel i5 1340P.

#!/bin/bash

cat /sys/class/power_supply/BAT1/capacity
cat /sys/class/power_supply/BAT1/status
echo - | awk "{printf \"%.1f\", \
$(( \
  $(cat /sys/class/power_supply/BAT1/current_now) * \
  $(cat /sys/class/power_supply/BAT1/voltage_now) \
)) / 1000000000000 }" ; echo " W";

running with watch -n0.1

This is the output near the end of charging (while the system is idling:

99
Charging
4.9 W

Shortly after it changes to

99
Discharging
4.6 W

Note that itā€™s instantly changing from charging to discharging. But the wattage still is around 5W, which is definitely not the actual consumption of the system. (On battery I measure about 15W idle)

When I cause some load on the system (by reloading YT subscriptions page for example), the wattage and discharge status doesnā€™t change.

The wattage does slowly go down however, as the battery actually still charges at this point.
2min later it looks like this:

99
Discharging
3.9 W

A while later (it takes almost an hour to go from 99% and charging with 5W to 99% and ā€œnot chargingā€ status.

99
Not charging
0.0 W

This should be the state where the system is fully charged and basically bypass the power directly.

If I now put some load on the system (refreshing YT subs), I get this for a short while:

99
Discharging
0.1 W

This stays for about half a minute or so until is switches back to ā€œnot chargingā€.

Now some comparison of the script when the system is on battery:

100
Discharging
14.6 W

Base load on idle. Interestingly enough, it switched to 100% charged when I unplugged it.

Reloading YT subs:

The wattage goes up to 19W in about a second, and peaks at 23W a second later. Then drops back down to 15W over the next 10 seconds.

Conclusion: No idea. It feels like the charging circuit canā€™t properly ramp up needed supply and uses the battery to supply the missing amps.
But that would also mean that the system would shut down if no battery is attached. That could be the next test.

1 Like

I tried disconnecting the battery (physically not via the bios) when debugging a different issue and the system runs fine, it doesnā€™t power down under load.

I encountered the same problem here, gaming in 60W means consistent(not just occasionally) flipping.

I found this research article, this is mainly about LFP battery, however, itā€™s mentioned that for any Li-ion battery that used graphite as anode, the degradation is worse when cycled 75%~100% four times(counted 1 cycle) compared to 0%~100% once(also counted 1 cycle). Thus, cycle 99%~100% one hundred times is going to wear the battery much faster compared to one full discharge-charge load.

In conclusion, battery flipping can be a reason why the battery pack degrades faster compared to the cycle life specified by the manufacturer.