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

[Charlie_6]

@James3

For example, my battery sits at -11 mA, but the charger has over 400 mA it is waiting ready to use, but the EC is not letting it provide it.

I made some measurements a while ago

[James3]

Those measurements are very useful.
I have tried some experiments on my FW16 with 25W charger.
Initial state always: Powered off, with charger plugged in.

Test 1:
Charge control state: NORMAL, Charging Battery.
This is mostly OK during boot. Some details I still need to investigate.
It boots to the grub boot menu.

Test 2: This is the interesting one.
Charge control state: IDLE, Charging Battery.
This goes crazy, battery -698mA, it somehow forces it to NORMAL state.
CL: p1 s0 i500 v5000 (forced) (2.5W power) in the middle of all this obviously does not help.
But, somehow it does manage to boot to the grub boot menu.

@Charlie_6
So, I can totally understand your measurements and saying the laptop will not even boot if the battery is removed.

In summary, I think the EC firmware control of the power is just crazy during the boot up process, and also crazy while in IDLE mode.

Another observation, the behavior in IDLE mode seems to be fine with a 180W charger, it just goes really crazy with a 25W charger.

I think this laptop would boot just fine with 25W charger and without a battery, if the EC firmware would stop doing the:
CL: p1 s0 i500 v5000 (forced) (2.5W power)
You really cannot boot a laptop on 2.5W of power. Caveat, setting it to 500mA is part of the USB PD standard, so hum!

Tests while booted into the Linux OS.
Test 3:
25W charger, charge control: IDLE
-11 mA battery, so discharging really slowly.

Test 4:
25W charger, charge control: NORMAL
644 mA battery, so happily charging on a 25W charger.

So, I have a theory, the laptop developers have known about this problem for a long long time, and instead of diagnosing it or fixing it, just force the charge control to NORMAL, is it sort of hides the problem.

The charge control code is really really complex, with various race conditions, so I don’t think I will get to fix it any time soon, but I will continue my diagnosis to try and get to the bottom of this problem.

I would be interested if others tested the following:
On a FW13, with a small watt charger, when in charge control IDLE, the battery sits at small negative value and says it is discharging.
At what size charger above the small watt charger, when in charge control IDLE, the battery sits at 0mA and not a negative value.
For me, on my FW16, that is 25W charger at negative -11 mA
180W charger at zero 0mA.

sudo ectool chargecontrol
Charge Mode: gives you the IDLE / NORMAL state.

Also, while in the IDLE negative charge:

sudo ectool chargestate param 3
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
49168 (0xc010)       # chg_status
sudo ectool chargestate param 4
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
50528256 (0x3030000)       # chg_option

And similar report what those values are when in IDLE zero 0mA charge.

sudo ectool chargestate param 3
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
114704 (0x1c010)       # chg_status
sudo ectool chargestate param 4
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
50534497 (0x3031861)       # chg_option

On the FW16, there is an ina236 chip that measures the Voltage and Current close to the USB PD input. I.e. before it hits the Buck/Boost DC-DC converters.
I have looked at their output and they match up fairly well with an external USB-C volt/current meter.
180W PSU:
Meter: 35700mV, 2300mA
INA236: 35400mV, 2300mA

25W PSU:
Meter: 8670mV, 2430mA
INA236: 8370mV, 2440mA

So, the INA236 seems to read about 300mV less than my Meter.

[Charlie_6]

@James3

I can totally understand your measurements and saying the laptop will not even boot if the battery is removed.

@James3

On a FW13, with a small watt charger, when in charge control IDLE, the battery sits at small negative value and says it is discharging.
At what size charger above the small watt charger, when in charge control IDLE, the battery sits at 0mA and not a negative value.

That’s the threshold, when the charger is above this wattage that battery no longer sits at a small negative value when charge control is IDLE, the computer can boot from this charger with the battery removed

[mgcarlson]

@Charlie_6

We can limit the CPU power to 25/29/45W when using 60/65/100W power supply to prevent the battery from flipping.

Adjusting CPU power limits by changing the Power Mode does appear to influence whether battery flipping occurs. Here are my observations of charging behavior when forcing a CPU spike by refreshing a browser tab with different capacity chargers attached.

• Power Saver Mode: No power draw from battery with both 60W and 100W chargers.
• Balanced Mode: -110mA draw with 60W charger. -1mA draw with 100W charger.
• Performance Mode: -120mA draw with 60W charger. -2mA draw with 100W charger.

Interestingly, with the 100W charger plugged in, I don’t see battery power draw regardless of Power Mode used if I don’t run screen recording software at the same time. That suggests to me that baseline CPU usage when the spikes occur contributes to whether battery flipping occurs.

See below video showing this behavior.

60W and 100W Charger Power Usage

@James3

If you could run my ec-syslog during the tests. (see previous message for how to install it.)
This will capture all the EC console logs into syslog. You can then post the ec-syslog log entries along with whatever tests you do.

I was able to compile the ec-syslog tool fine, but I get the following error when I try to run the script.

sudo ./ec-syslog 
thread 'main' panicked at src/main.rs:21:37:
called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Also, I believe Fedora uses /var/log/messages instead of var/log/syslog to log system outputs. Is your script set up to write log entries to that location?

[James3]

@James3

sudo ectool chargestate param 3
sudo ectool chargestate param 4

Please can you post the output of the above 2 ectool commands for each charger.

[mgcarlson]

The output is the same for both the 60W and 100W chargers.

sudo ectool chargestate param 3
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
49168 (0xc010)       # chg_status

sudo ectool chargestate param 4
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
42926080 (0x28f0000)       # chg_option

[James3]

@mgcarlson

I was able to compile the ec-syslog tool fine, but I get the following error when I try to run the script.

You need this kernel module loaded for ec-syslog to work:
sudo modprobe cros_ec_debugfs
It creates a file in
/sys/kernel/debug/cros_ec/console_log

[James3]

Well, I think there are two main problems / symptoms I have seen:

1. small negative discharge currents while running.
2. the laptop renegotiating usb pd power profiles while booting.

For (1),I feel I have a few things to try, but don’t fully understand the charge circuitry/chip to be confident it will help. FW do not publish the charge circuitry.

It is interesting that my 180W psu puts the FW charge chip into a “bypass” mode when idle. But both your FW13 60W and 100W do not put the FW13 chip into “bypass” mode.
I think the theory is, if the psu supplies 20V to the chip, it just passes through that 20V to VSYS as they are compatible.
If the FW13 100W charger is running at 20V, why isn’t it doing a “bypass” also?
My guess is the FW13 does not have the bypass circuit.

2. For this, it negotiates charge volts/amps during power on of the cpu. Then transitioning to the new power volts goes via a 2.5W power stage so pretty much turns off the power in the middle of booting the cpu, thus the battery has to quickly take over or it crashes.
   My fix for this would be, if it thinks it needs to go via a 2.5W transition, do it before booting the cpu. I.e. while only the EC is on.
   Also the EC power negotiation code is messy and racey and I don’t see it behaving as per the usb pd standards in some places.
   I assume it’s best to negotiate the highest voltage available from the psu and then stick with that. The EC does not do that, but it might have a reason for it. I am still investigating this area of the usb pd spec.

The rest of this thread, I will focus on (1).

[Charlie_6]

@mgcarlson

Adjusting CPU power limits by changing the Power Mode does appear to influence whether battery flipping occurs. Here are my observations of charging behavior when forcing a CPU spike by refreshing a browser tab with different capacity chargers attached.

• Power Saver Mode: No power draw from battery with both 60W and 100W chargers.
• Balanced Mode: -110mA draw with 60W charger. -1mA draw with 100W charger.
• Performance Mode: -120mA draw with 60W charger. -2mA draw with 100W charger.

Even the CPU spikes, the battery shouldn’t discharge as the boost power is only 53W in performance mode (51W in balanced), far from 100W. From my measurements it consumes 73W for a few seconds then down to 45W(35W on the CPU). I think the problem is the VRM or whatever the DC-DC converter can’t catch up instantaneous load and it’ll discharge the battery momentarily (less than 1 second)

@James3

The new EC firmware should fix the “Battery flipping” issue.

Could anyone test the maximum power draw with the battery removed and compare it with the charger wattage and see if there’s any improvement using the new EC code.

@Charlie_6

For some reasons the presence of the battery itself enables higher utilization from the USBC input even when the battery is charged to 100% or the charging limit you set.

30W charger: flipping when overall system load(NOT CPU load) <27W, discharging when overall system load >27W.
60/65Wcharger: charging when <33/37W, flipping when 33/37W<overall system load<54/58.5W, discharging when >54/58.5W
100W charger: charging when <57W, flipping when >57W, it’s not possible for overall system load to reach 90W

[James3]

Just for clarity, my new EC firmware does not fix the “Battery flipping”.
It fixes flipping cased by transitions in higher level NORMAL, IDLE and DISCHARGE states.
But after fixing that, a separate cause was discovered.
I am investigating this separate cause now. It is somewhat complicated, so progress is slow.
For example “100W charger: charging when <57W, flipping when >57W, it’s not possible for overall system load to reach 90W”. Why would that ever wish to draw from the battery? There is always the instantaneous current demands. The cpu might draw 500W for a millisecond, but when averaged over a second could still average to less than 100W.
The buck/boost is a half cycle power supply, where for half the cycle it fills a bucket, and the other half it let’s it slowly empty. There are also limits on how much it can fill each time (size of inductor) and how big the bucket is (size of capacitor). You can also adjust how often it fills (frequency).
So really, PSUs should publish not only there long term sustained current they can provide, but also the instantaneous peak current they can supply, but none of them do.
Then one could know the instantaneous peak current the cpu needs, and match the buck/boost to it.
So, we are trying to solve a problem here with a lot of unknowns still to be discovered.

[mordisko]

I’m experiencing a constant charged/discharged battery, causing the percentage to fluctuate between 99% and 100%. Battery is quite hot.

Framework Model:

Framework Laptop 13 AMD Ryzen AI 300 series (AI 9 HX 370)

Distribution and release affected:

Ubuntu 24.04.2 LTS

Your upower version:

1.90.3-1

BIOS version:

	Vendor: INSYDE Corp.
	Version: 03.03
	Release Date: 03/10/2025
	ROM Size: 32 MB

Confirming yes or no you are using stock power management:

Yes, using stock power management

Power adapter used:

Mine. Tried two adapters:

1. UGREEN x559, 65W,
2. The adapter from a Mac Pro M1 (2020), 140W

** Which expansion bay are you connected to for power:**

Top right.

[Will_Nilges]

My batt gets warm while charging but not hot. Especially when I am at my charge limit. You should definitely contact support about that.

[mordisko]

I apologize, “hot” was a poor choice of words. I don’t know if there’s a specific sensor in the battery, but the ones present range from 42 to 52 degrees celsius.

[James3]

You can read the battery temp from the battery itself.
sudo ectool chargestate param 6

The value is in deci-kelvin.
E.g. 3055 is 305.5 Kelvin.
305.5 K - 273.15 = 32.3 C

[Charlie_6]

I got this

$ sudo ectool chargestate param 6
EC result 3 (INVALID_PARAM)

Why?

[mgcarlson]

After some troubleshooting, I got the ec-syslog tool to work.

The trick was installing the kernel-debug-modules version of the Linux kernel, and then booting into the debug kernel on system restart. The debug kernel comes with cros_ec_debugfs by default, the standard kernel does not.

While running the browser refresh test from my previous post (battery at 80% charge limit, 100W charger plugged in), here is the ec-syslog output I get. I filtered out the PORT80 messages that corresponded to me refreshing a browser tab.

sudo less +F /sys/kernel/debug/cros_ec/console_log
[258277.481800 charge_request(16776mV, 0mA)]
[258277.733300 charge_request(16768mV, 0mA)]

I observe that the same charge_request messages occur regardless of what Power profile I use, even though the current usage is higher in Performance mode vs Power Saver mode.

Here are the ec-syslog outputs using my 60W charger under the same test conditions. I’ll occasionally see voltages of 16720mV and 16744mV in the charge_request messages using a Performance Mode power profile, but there’s no consistency to when that occurs.

sudo less +F /sys/kernel/debug/cros_ec/console_log
[260912.396900 charge_request(16760mV, 0mA)]
[260912.645700 charge_request(16752mV, 0mA)]

[James3]

@Charlie_6

I got this

$ sudo ectool chargestate param 6
EC result 3 (INVALID_PARAM)

Why?

Hi,

I don’t know.
Does ectool chargestate show

Give anything?
Obviously, it depends on the battery.
I can only test on a FW16 that I have. I don’t have a FW13 to try on.

[James3]

Hi.
Regarding the charge request values.
I don’t yet know why it needs to send any of them when it’s not charging.
The 0ma bit says don’t charge, I don’t yet know why it needs to keep changing the mV if it has no intention of doing any charging.

[Matt_Hartley]

Hi everyone,

Good news! The Framework Laptop Ryzen 7040 Series BIOS 3.09 (yes, the numbering is intentional) is available in Beta status.

Please check out this link below:

Framework Laptop 13 Ryzen 7040 BIOS 3.09 Release BETA

NOTE: Once you update to 3.09, you cannot downgrade to 3.05 or the version earlier than 3.05. Highlights Fixed the battery extender setting overwritten battery charge limit on boot. Fixed battery charging limit is reset by the battery extender reset timer. You can check your current BIOS version following the steps here to determine if you are on the latest release. After the beta release, we will monitor community feedback, and publish this release to our stable release channel after appro…

[frameworkanon]

I’m having this issue with the HX 370, the same as mordisko so I’m unsure if it’s related with the 7040 series.