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

I have it too. And I found this:

Would be very useful for battery calibration though. A thinkpad style battery recalibration mode would be nice where it completely discharges then charges the battery while connected to ac.

Very nice that people are starting to play with the ec, keep it up.

I have a version of “ectool” here:

It fixes a few things, but more recently, fixes the “ectool chargecontrol” command so that it does not disable IDLE mode, that I warned about previously.

1 Like

Does this mean it is resolved in Arch? when does that move to fedora?

Once the new version of upower hits the stable repos. It will fix the “annoyance” of the plugged/unplugged

https://bodhi.fedoraproject.org/updates/FEDORA-2025-7fe27371fb
https://bodhi.fedoraproject.org/updates/FEDORA-2025-cc92961dbb

Can anyone point me to the patch that fixed upower ?

I saw this one, but my Linux kernel 6.14.2 does not surface
/sys/class/power_supply/BAT1/charge_control_end_threshold
The file does not exist.

I was trying to understand what upower got wrong, in case it affects my EC fixes I am working on.

I have not yet looked at the “battery extender” code to see how that interacts with my current EC fixes.
I just leave the “battery extender” BIOS setting to disabled at the moment.

edit:
My changes to the EC code break the battery extender function.
For example, with my changes:
If you set the charge limit to 60% and enable the battery extender function.
When the battery extender triggers, it will charge up to about 85%
If you set the charge limit to 100% and enable the battery extender function.
When the battery extender triggers, it will not do anything and stay at 100% charged.
If the battery extender triggers at any time, and the current charge is less than 85%, it will charge up to 85%, ignoring the charge limit setting.

Without my EC code fixes:
When the charge limit is set below 85%. If the current charge is less than 85%, and the extender triggers, it will try to charge up to 85%. It will battle with the charge limit setting, looping round charge/discharge on about 1 second cycle.

I have pushed my EC changes to this repo for the Embedded Controller of the FW16.
Note: This makes no changes to the EC code for the FW13. I don’t have a FW13 to test with, so cannot help much there, but I think my changes would help the FW13 also.

My changes are on the branch:
fwk-lotus-azalea-19573

“lotus-azalea” is the FW16.

In the output of:
sudo ectool chargecontrol

With PSU connected:
NORMAL == Charge battery if there is spare PSU capacity after powering the CPU/GPU.
IDLE == Don’t try to charge or discharge the battery. Only power the CPU/GPU.
DISCHARGE == Disconnect PSU, discharge even with PSU connected.

With PSU disconnected:
NORMAL == expect to start charging when PSU plugged in.
IDLE == should not see this.
DISCHARGE == should not see this. (after my EC fixes)

sudo ectool battery
in the “Flags” part:
CHARGING == ignoring any charge limits, the battery would like to be charged.
DISCHARGING == extra power is being provided by the battery to the CPU.

If the PSU is connected, and you see ectool battery DISCHARGING, it means the CPU needs more than the PSU can give, and its getting the extra from the battery.
The ectool chargecontrol should still say “IDLE” while power is being used from the PSU and the Battery at the same time.
If the Battery discharges below a threshold, the ectool chargecontrol should change to “NORMAL” so that it starts charging if the CPU/GPU power usage drops again.

2 Likes

The logic sounds reasonable to me.

This is the upower issue: https://gitlab.freedesktop.org/upower/upower/-/issues/306#note_2856003 (probably best to start reading at this thread, the issue is pretty chaotic). The problem was that upower started to ignore the charging state reported by EC and instead said “discharging” even when EC says charging but the battery current is negative. This was to make upper layers aware of situations in which the PSU is not powerful enough so that they can still react to low-battery states, e.g., shutdown when battery < 5%.

1 Like

If you can put together some documentation, I would be willing to test changes on the FW13 for you. I have a Ryzen 7040 series machine :slight_smile:

No disrespect to @James3 intended whatsoever but I’d be really sure about how using custom ‘homebrew’ firmware affects your warranty & any future support before proceeding. Not to mention risk of straight up bricking your laptop. I guess most people knowledgeable enough to consider trying this understand the risks but worth reiterating.

I opened an official support request yesterday for the fact that battery status switches to discharging even when I have AC plugged-in (only with FW 60W charger, not with my Satechi 100W). I’m working through the support email troubleshooting process

definitely a good point. That reminds me that I meant to open a support ticket too! I am just so used to eBay thinkpads that I forgot I can do that :smiley:

That said, I am aware of the risks and if I can get information on how to safely flash my EC I don’t mind helping out if it helps others in the community as well :slight_smile:

1 Like

I think one frustrating thing here is that FW released a new version of the EC firmware in the latest FW13 BIOS update, but have not published into the github repo what changes they made to the EC firmware.
People have reported battery problems with that latest firmware and I now understand the EC firmware source code enough to finally test and fix the bugs they might have introduced.

As an example as to how crazy the firmware is.
It has 3 different algorithms for battery management that all run at the same time. It applies the result of one algorithm, then a second later applies the result of the second algorithm, and occasionally applies the results of the third algorithm.
As all 3 are very different algorithms, they of course argue and are flipping back and fourth between the various algorithm results. This is what is causing the flipping between charging and discharging. One algorithm is telling it to charge, and the other algorithm is telling it to discharge.
So, one of the bug fixes I did to the firmware was:

  1. disable the third algorithm entirely. (leaving just 2 algorithms to fight is better than 3)
  2. when the second algorithm is running, suppress the first algorithm.
    My patch actually prints a EC console message when it is suppressing the first algorithm.
  3. when the second algorithm is not running, use the first algorithm.

The result of the bug fix is that only one algorithm is actually permitted to run at a time, resulting in a sensible outcome.

It is only really me putting a plaster on it.

The correct answer is to have a single algorithm that handles all the needed edge cases that the 3 algorithms are trying to handle.

So, that is just one example of how crazy the EC firmware is.

4 Likes

Wow, I guess I would be really curious to know how that made it into production. Do you know if this is the same for the Intel boards?

I am still running 3.05. Are you able to prepare something for me to test?

@Will_Nilges
I am quite cautious about bricking the laptop so I have created some tools so that it makes it very difficult to accidentally brick the laptop. I have a pretty safe way of experimenting now.
The problem is it involves compiling code from about 4 different repos and then following a specific set of steps to try things out.
In summary, its going to take me quite a few hours to write up the instructions and steps. I am hoping to find the time this weekend, but cannot promise anything.

3 Likes

Ah, I gotcha. Well I very much appreciate your work and let me know if you are able to do so. In the meantime I will also open a ticket with Framework about this because while I am not sure it’s explicitly harming my system it is concerning.

If left unchecked, what effect would this have on the health of my system?

In at least one of the branches, there’s this comment:

Some boards have a sing capacitor problem with mode == IDLE. For such
boards, a host can specify EC_CHARGE_CONTROL_FLAG_NO_IDLE, which
makes the sustainer use DISCHARGE instead of IDLE. This is done by
setting lower != upper in V2, which doesn’t support the flag.

I’m most definitely not an EE so I might be mis-interpreting this, but: This reads as some boards are electrically not capable of true “idle” in terms of (dis)charging. Do we know which those boards are?

1 Like

There is that comment. But I don’t think that code was written by a FW developer. I think it was written by someone at google. So “some boards” could mean some board that is in the wider market, and not necessarily a FW mainboard.
My FW16 mainboard definitely supports IDLE.

1 Like

Just got home and docked my laptop and another weird thing happened: my laptop seemed to still be discharging. Unplugged and replugged my dock and it started charging again. Thought it was worth mentioning because that’s the first time I’ve seen that behavior. I’m using a ThinkPad USB C Dock Type 40A9

I made a reply above a while ago, it’s about a portion of power input not available without using the battery


It’ll discharge the battery at about 10mA.

Sorry what?

As long as the system’s overall electrical load is significantly below the charger’s capacity (so we don’t need to worry about losses/overhead etc), the battery ideally shouldn’t be under any load whatsoever. But again, I’m not an electrical engineer…

That’s what the code comment says, maybe meant to say sink?