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

[mgcarlson]

I can confirm I am on the RW image.

sudo ectool sysinfo
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
Reset flags: 0x00000448 (power-on hibernate sysjump)
Firmware copy: 0x02:RW
Jumped: yes
Recovery: no
Flags: 0x00000008 ( unlocked )

I intend to keep my upper charge limit at 80%, so I just disabled battery extender in the BIOS since its functionality seems redundant now. With my upper charge limit at 80% and battery extender disabled, here are the chargecontrol3 outputs I get.

sudo ectool chargecontrol3
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
Charge mode = IDLE (1)
Charge state change counter = 15
Battery sustainer slot = 0
Battery sustainer[0] = (75% ~ 80% ~ -1%)
Battery sustainer[1] = (0% ~ 0% ~ 0%)
Battery sustainer[2] = (0% ~ 0% ~ 0%)
Battery sustainer[3] = (0% ~ 0% ~ 0%)

I am currently using the 60W power adapter from Framework I bought with the laptop.

With the laptop plugged in, and at full 80% charge, if I perform an action that puts a moderate load on the CPU (i.e. refreshing a browser tab rapidly), the Flags output from sudo ectool battery changes from a Charging state with almost no current draw (0mA to -1mA) to Discharging with about -5 mA current draw for 5 seconds.

Based on that, I think your IDLE logic works as intended. Possibly the Framework charger is undersized for the current required by the laptop under CPU loading? I unfortunately don’t have a USB C charger with a higher power rating at the moment to test this with.

sudo ectool battery
# Do nothing on the laptop.  Default flag state at 80% charge limit is the following.
Present current         0 mA
Flags                   0x0b AC_PRESENT BATT_PRESENT CHARGING
# Load the CPU by refreshing a browser tab rapidly.
Present current         -5 mA
Flags                   0x07 AC_PRESENT BATT_PRESENT DISCHARGING
# Wait 4-5 seconds for the refresh to complete.  Current slowly drops from -5 mA or so back to 0 mA.
Present current         0 mA
Flags                   0x0b AC_PRESENT BATT_PRESENT CHARGING

Reading battery temperature using sudo ectool batterytemp seems to be working fine. Might set up a script to log battery temperature over time in the future to see if it holds steady under idle conditions. Here is a sample output from that command.

sudo ectool batterytemp
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
battery_temperature_in_C: 35.4

@Will_Nilges
I am running BIOS 3.07 currently. I meant to stay on BIOS 3.05, but accidentally installed the update during a software upgrade.

[James3]

Please can you copy the full output of the “sudo ectool battery”.
You can remove the serial number line if you wish, but I wished to see all the other lines.

Can you post the output of “amdgpu_top”.
I am curious as to how close to 60W it thinks you are getting.

Also, what is the output from “sudo ectool chargestate show”.
It should show how much charge/power the PSU thinks it can provide.

The batterytemp looks fine. It gets interesting when it get above 50-55 C .
If the battery gets too hot, you can use ectool to force the fans on, and that cools it down a bit.

Is the “charge state change counter” increasing?
It should increase 1 with PSU disconnect, and increase 1 with PSU connect and then also increase if the IDLE state changes to something else.
But, if you leave the PSU connected, it should just stay at the same value and the “Charge mode” should stay in IDLE state, assuming the battery is staying between 75 and 80%

I can sort of reproduce what you are seeing, if I plug a 25W charger into my FW16

Seeing a -5mA discharge is pretty small, so it must need just a very little bit more than the PSU is delivering.

[mgcarlson]

The charge state charge counter updates when I unplug the laptop. The counter does not immediately increment when I plug in the PSU. It updates when plugged back in after the charge limit is reached and a transition from NORMAL to IDLE mode occurs.

Here is the full output from sudo ectool battery at the max charge limit of 80%.

sudo ectool battery
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
Battery 0 info:
  OEM name:               NVT
  Model number:           FRANGWAT01
  Chemistry   :           LION
  Serial number:          0099
  Design capacity:        3915 mAh
  Last full charge:       3999 mAh
  Design output voltage   15480 mV
  Cycle count             3
  Present voltage         16785 mV
  Present current         0 mA
  Remaining capacity      3180 mAh
  Desired voltage         17800 mV
  Desired current         3915 mA
  Flags                   0x0b AC_PRESENT BATT_PRESENT CHARGING

If I allow the battery to go below 80% and then reconnect my charger, here is the output from sudo ectool chargestate.

sudo ectool chargestate
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
ac = 1
chg_voltage = 17800mV
chg_current = 2740mA
chg_input_current = 2700mA
batt_state_of_charge = 79%

Here is a video showing amdgpu_top and other ectool outputs while refreshing a random browser tab in Firefox. The current usage went as high as -100mA.

amdgpu_top outputs

[James3]

Hi.

It appears the PSU is offering 48W to the charger.
But when you click the refresh button, its getting to 20W in amdgpu_top most of the time. It sometimes gets to 50W for an instant.

Would you be able to unplug the charger.
Then plug the charger in, and as soon as you can after that type “ectool console | grep CL:”
It should output stuff looking a little like this:
[235.827900 CL: p2 s1 i500 v5000]
[236.083100 CL: p2 s0 i4500 v20000]
[236.432800 CL: p2 s0 i5000 v36000]

Note: I am on a FW16 with a 180W charger, so 5A * 36V = 180W, to match my FW charger.
Your 60W charger should give some output that matches up to 60W. e.g. i3000 v20000 or something like that.

My FW16 with a 180W charger, offers up about 120W to the ectool chargestate.
So, yours offering about 48W seems comparable.

I am thinking that the 60W charger is just a little bit too small for the FW13 AMD 7840U that you have. Either that, or there is a fault on your mainboard, that is drawing a little bit more than is should. I think the only way to tell, would be for other users to run the same tests you are, and see if they can reproduce your problems. If they can reproduce your problems, your mainboard is fine, and its just doing this by-design.

This thread implies that a 100W charger can be used with a FW13:

[SOLVED] Max wattage for charging

Hello - I apologize in advance if this is a simple question, but I wanted to ask and learn so I don’t potentially mess up my laptop battery. I have a 13 with the 12th gen Intel board. I know the power adapter that came with it is 60 watt. However, I want to buy an Anker or UGREEN charger block that can handle multiple devices at once. One model I was looking at offers one port that delivers 140 watts. The others are less, and the lowest powered port does 20 watts. Ultimately my question is, wil…

This is an interesting finding, because although my fixes did fix some edge cases, your particular edge-case is a new one. But I think it is only been discovered for sure once my fixes ensured that the chargecontrol would reliably stay in the IDLE state.

Just out of interest, which “power mode” are you running with?
The options on my FW16 are: Performance, Balanced, Power-Saver

The current usage at -100mA * 16785mV only equals about 1.7 Watts of power it is taking from the battery.
So, maybe even a 62W charger would be enough to cure the problems, but a 100W would be better.

[SkaveRat]

Regarding the short power draw:

I’ve mentioned it previously here in this thread during my debuggin, but in my case I can 100% reliably trigger the “short dip into the battery” problem if I have frequency boosting enabled on my Gen13 i5. (and then do anything barely load-inducing. Like opening youtube).

I disabled boosting via TuneD and it barely happens anymore.

This happens regardless of how powerful the charger is that I use (even a UGREEN Nexode 100W charger. Ugreen cables).

Note that I’m still running the latest official firmware. Just want to add this as a note

[James3]

@SkaveRat
That is a good bit of measuring you have been doing.
Drawing from the battery while using a 100W charger … the plot thickens.

You mentioned it a while back, but did you measure what happens if you remove the battery and then trigger the situations that previously draw from the battery.
What happens then? Does the CPU crash or anything like that?

[mgcarlson]

I am using the Balanced power mode in GNOME 48 on Fedora 42.

I started my laptop from a shutdown state without being plugged in, which switched me to the RO image. And since I was on the RO image again, my charge limit was ignored per the known bug in the v3.07 EC firmware.

Do I always need to go back into EFI to re-enable the RW image, or is there a simpler way to do it?

Anyways, after waiting for the battery to discharge to about 75%, here is the output from the ectool console command immediately after plugging in. Unsure what the “Forced” portion of the second line refers to, but it does show my 60W charger on the final line.

sudo ectool console | grep CL:
[5562.531600 CL: p3 s1 i3000 v5000]
[5562.561000 CL: p3 s0 i500 v5000 (forced)]
[5562.797100 CL: p3 s0 i3000 v20000]

[SkaveRat]

Doing some tests with the battery unplugged.

So far, no problems at all.

• FW13 13gen i5-1340P

• TuneD profile “desktop” (basically full performance)

• All tests done with a 1.5m Ugreen usb cable.

• Using the top right USB port

• While the battery was still plugged in, I could reproduce the “now discharging” problem (just to confirm)

• 100W Ugreen charger: No problem

• “145W” Ugreen Powerbank: 100W port: No problem. 45W port: no problem

• 45W Ugreen charger: No problem.

I could also test with the official charger and a 65W ugreen charger, but I’m not sure if that would give more results.

In fact, I’m writing this while using the 45W charger. While also having 16 threads of “md5sum /dev/zero” in the background to fully saturate the CPU.

The laptop just doesn’t care and keeps running.

Here’s the frequency graph and thermals of the current run:

I’m probably running more into thermal throtteling than power throtteling.

Only “weirdness” I observed was the fact that the laptop took a while to actually boot, when plugging in the power. (e.g. took up to half a minute of pressing the power button a couple times for the laptop to boot into the FW logo)
Edit: laptop is doing the same when moving back to battery and AC, so I assume it’s just the bios figuring out its new situation

Another situation I could test: Using the 2-port 45W charger with another framework also plugged in. I know that my laptop uses ~20W while doing things like watching a video, so that would very likely max the power usage out

[Will_Nilges]

@James3

I am thinking that the 60W charger is just a little bit too small for the FW13 AMD 7840U that you have.

I see a similar behavior on my (stock) 3.05 BIOS board. I see the charge/discharge flipping on all 65W chargers I own, but on my 96W Apple charger, it’s totally stable in “Charging” at all times. I’ve verified this with stress -c 16.

[James3]

Thank you all for providing some excellent observations.
I think there are probably multiple unknown bugs or designed behaviour causing what we are seeing.
It has given me an idea for some more tools to write in order to gain more information.
Essentially, what I think I need is

1. high resolution (small time between samples) for all measurements to gain good time series data.
2. measure battery negative currents.
3. measure how much power the cpu/gpu wants at any particular instant.
4. full continuous ectool console output or output from an EC CCD.
5. measure how much power the charger can supply.
6. measure charger CL changes.
7. measure the normal, idle, discharge state.
8. measure slowness. I.e. those times when it boots slowly. Some how create time series data from it.

I think these problem events are very short instance so catching them will be hard.
We are lucky with the negative battery measurements because the circuitry smooths out the spike over a number of seconds so it becomes obvious to see. Catching the spike in other measurements will be hard.
Note: I am calling it a spike just to give it a name. It could be anything at this stage.
If anyone has any ideas of affective ways to get the high res measurements, it would help.

[James3]

@mgcarlson

Do I always need to go back into EFI to re-enable the RW image, or is there a simpler way to do it?

Switching between RO and RW images causes an immediate uncontrolled shutdown of the CPU.
Doing this uncontrolled shutdown while in EFI shell is not bad. Doing it while in an OS is possibly bad.
There used to be a method to schedule a switch at the next controlled reboot, but that does not seem to work now.
So, although you can switch within the OS, it’s not really a good idea, so that is why my instructions use the EFI method.

[James3]

@mgcarlson

[5562.561000 CL: p3 s0 i500 v5000 (forced)]

I looked into the “forced” bit in the EC Firmware code.
The charge current/volt control code is a little difficult to follow.
There are even comments in the code saying "… it’s too complicated to guarantee … "

The “forced” bit in the code is used to “… prevent race conditions …” but sounds like a sticking plaster at best.

I have never seen the “forced” message on my FW16, but that is not to say it might happen.

I have created a tool called “ec-syslog” that you can compile from here:
git clone GitHub - jcdutton/FW-firmware-tools: Tools to compile, install and control Framework Laptop Embedded Controller Firmware

cd FW-firmware-tools/ec-syslog

cargo build
sudo ./target/debug/ec-syslog

It will capture all the EC console logs and send them to local syslog.

[sydney]

FWIW, i have the same issue with the original FW 60W charger, bought some Anker 100W usb-c charger that negotiated sucessfully at 20V/5A, and still faced the issue. Subjectively, the charging state flipping here mostly happens with bursty single thread loads while on the “balanced” ppd-profile, noticably less so but yet still also with the power-saver profile.

[sydney]

@Matt_Hartley

@sydney

Just to clarify, a permanent resolution to the power management issues or the freeze-then-reboot issue?

We’ll have a list of changes and related when the release drops.

@Matt_Hartley

@Quin_Chou released the beta announcement of BIOS 3.09 with the list of changes.

The freeze-then-reboot issues are not mentioned once in the release information.

Does this mean framework support is not working or even acknowleding/aware of the issue, then?

[James3]

@sydney
Did you mean that for a different thread, perhaps the BIOS 3.09 thread?

This thread is just for “battery flipping” fun !!!

[sydney]

@James3 I understand, and i’m going to desist from continuing to do so.

But you do understand what it is, that am asking with this, frankly?

I mean, completely apart from the battery flipping issues or even the FTR issues?

If this is the case, then FW should show some respect, and simply say so. Without giving people the run-around and doubtful avowals.

I do not appreciate pettifoggery.

[Will_Nilges]

I think the trick is enough people need to open support tickets and point them at the thread. Also probably tag Matt in the thread at this point.

[mgcarlson]

Stopped by the store today and picked up a 100W Insignia charger (5A, 20V per ectool console). Waiting for my laptop to charge, and then I’ll rerun the amdgpu_top and ectool tests from yesterday again. Any other outputs of interest that my last video didn’t show?

[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 am working on creating a data collecting tool, but that is some way off yet.

[James3]

Hi,

I am making some progress with tracking the problem down.
I have been able to reproduce the problem on my FW16 that people are seeing on their FW13.
Essentially, a PSU has enough power, but the EC is miscalculating that, resulting in the battery discharging a little.
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.
The maths used in the EC is not great, it does various calculations but does not check at all for any overflows. It uses 32bit int when getting very very close to overflowing the 32bit int using microwatts.

For example, a max int is: 2,147,483,647
36000 * 5000 = 180,000,000
Multiply that by 12 and you are in overflow country.

I don’t have a fix yet, but at least I have a very good idea as to where to start looking.

FYI, I manage to reproduce the problem by using a 25W charger powering a FW16.

So far, I have established that the values read from the battery are mostly accurate.
The charge controller is another matter. The calibrations or calculations around that are all over the place and currently make no sense to me. I need to investigate further, but making progress.