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

Framework Laptop 13 Linux
252

Thanks, believe this is what you are referring to. But, again, we require the needed details requested as well.

253

Thank you for the response, Matt, I do appreciate it.

I did offer my details earlier in this thread: [TRACKING] Battery flipping between charging and discharging / Draws from battery even on AC - #157 by Will_Nilges

I also exchanged 27 messages with support about this issue since April 17. This includes lots of time spent testing and re-testing my charging setup under various chargers, port configs, loads, and OSes. Even after an escalation, the answer I got was: “Wait for the new BIOS.” However, as I am sure you are aware, a new BIOS for the 7040 board has not made it to stable in over 5 months after three (3) false starts, and there has been no further communication about next steps, timelines, etc. from anybody about it since Apr 14.

I am feeling frustrated because I did all of this work with support, and it still feels like we’re being ignored. If you personally have not read this thread in its entirety, I implore you to do so. James seems to have straight-up solved the bug in his fork of the EC firmware and I’m sure they would be more than happy to work with you and the Framework team to upstream these changes into a proper BIOS release.

Most of all, I just want to know when the next BIOS will be available. If Framework has the resources to ship two entirely new products this year, then what is taking so long to update a few hundred lines of C code?

7 Likes
254

Ah yes, I see it now. Going over this now. Thanks for calling this out. Both your link and also the solution provided by James.

Current BIOS for 7040 Series is 3.07. Are you inquiring a version after 3.07 for AMD 7040 Series?

I also noticed that it looks like your ticket for this issue, with the last replied was closed on April 30th. Was this in error on our part? Looks like an agent may have inadvertently closed the ticket.

If this is what happened, I deeply apologize for this misstep and will follow up internally to find out what happened.

For the solution provided by James, I will be sharing this with the engineering team as well.

1 Like
255

I am sharing this internally now, thanks for calling this out.

1 Like
256

@Will_Nilges Digging into this a bit more (your ticket), are you still on 3.05 or were you able to get to 3.07 successfully? If not on 3.07, I would like to offer my assistance to get your BIOS updated to current.

I also acknowledge the git repo fork above for EC, but wanted to clarify you are on current BIOS as well.

1 Like
257

Thank you, I very much appreciate your time and effort in getting this matter resolved.

I am still running BIOS 3.05. BIOS 3.07 was held and not promoted to stable due to a bug in the charge limit. That BIOS was superceded by BIOS 3.08, which attempted to fix those bugs, but was also held in BETA and also not being promoted to stable for bugs with the interaction between the charge limit and battery extender. So, in a way, I am inquiring about what will probably end up being 3.09, which will hopefully put all the issues with 3.06, 3.07, and 3.08 to bed. As I mentioned in my support tickets multiple times, I am on 3.05 still because of these issues. There has not been another stable BIOS since 3.05.

The ticket being closed is definitely a mistake (and no worries, mistakes happen). I am still having this problem and it is not resolved.

I do appreciate the apology. We’re all human. My goal here is to get bugs squashed, security holes patched, and prompt, thoroughly tested software and firmware support that customers deserve. To that end, I understand that these things take time, and I would like more transparency in the development process. In the case of the AMD BIOS issues, I think weekly status updates would be warranted.

Please keep us updated about what engineering says about James’ patches.

5 Likes
258

@Will_Nilges With the patience of an angel :slight_smile:
Dear Lord.. that you’ve even had to explain this stuff.
BTW: I have a new ticket with them and have been told the issue had been “escalated”. Frightened already.

In the ticket, i also referred FW support to the following github issues on framework’s own github account.

Perhaps @Matt_Hartley might be interested in having a look at least at @James3 's work.

3 Likes
259

Hi @Will_Nilges,

We have reopened your ticket for review. Again, we apologize for any miscommunication regarding the ticket closure.

2 Likes
260

Hi folks,

I’ve spoken with the appropriate teams, and we want to be clear: we hear you, and we take this seriously. This originated from a user who was understandably frustrated and created their own workaround—which we now see has been made into an easy-to-use tool.

We appreciate the community’s initiative, however, the permanent resolution is in progress and on track for release when it’s ready.

While we fully support community innovation, it’s important to note that modifying firmware or hardware in unsupported ways may void the device warranty.

Thanks again for raising this—and for pushing things forward.

Appreciate everyone’s attention to this.

Matt Hartley
Framework Linux Support Lead

3 Likes
261

@Matt_Hartley Thanks a bunch for looking into this..

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

2 Likes
262

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

263

@Matt_Hartley Are you at least aware and working on the freeze-then-reboot issue, then? If i may ask, of course..

2 Likes
264

Thank you for checking in with the teams, and I do really appreciate your care and attention on these issues.

Echoing sydney, I would appreciate a clear and explicit statement on the timeline of resolution for:

  • The FTR issues on the FW 16
  • The charge/discharge flapping issue on all machines
  • The next FW 13 Ryzen 7040 BIOS release

on track for release when it’s ready.

Please, at the very least, can you let us know if Framework expects these fixes to take weeks or months? It has been one month since the 3.08 BIOS release. In that post (which I linked earlier), it was stated that release would be promoted if there were no issues reported. Issues were reported, the release was held, and then there was no update besides “we’re working on it” with no ETA. Surely, Matt, after all that we’ve told you, you can understand how “we’re working on it” is not good enough for us now that it has been five (5) (FIVE) months since we’ve started this debacle? We need an ETA, and we need that ETA to be accurate.

4 Likes
265

I do understand, I do. Keep an eye on this thread. The moment I get a ping on the update, this will be the first on my list.

266

Hear hear.

267

@Matt_Hartley
Thank you for taking an interest in our problems we are having with FW laptops.
I think the FW approach to BIOS and EC updates is flawed.

  1. Any test or beta update MUST be able to be rolled back.
  2. If a user reports a problem, that user should be offered an Alpha bios to test if it fixes the problem for them, before rolling it out to everyone.
  3. The EC, USB, PD firmware does not have to be linked to a BIOS update. All should be able to be released individually, then rolled back if the user wishes to roll them back.

The latest FW16 BIOS was an epic example of this process failing. Users waited ages for a BIOS update to fix their charging problems, and when it finally arrived, it did NOT actually fix it.

The above described process is used by HP, Dell, ASUS and Supermicro. I know because I have examples of resolving BIOS bugs with all of them.
It is a process that works. Maybe FW would like to consider following it.

FYI, I have the very latest BIOS on my FW16 but we also have reports of charging problems across all FW13 from old intel ones, through to the latest amd ai 390 series mainboards. It is a problem that affects both Windows and Linux users.

On a more positive note, the EC code is open source. It was really really crazy code up to about 6 months ago. It has greatly improved more recently, but still does not fix all the edge cases.

If you want clarity regarding the “crazy” comment, I have gone into detail about it previously on this thread.

So, a BIOS release now, using the current EC code in the FW github will NOT fix the charging problems for users because it does not cover all the problem edge cases.

As said earlier, I have published all my proposed changes to the EC code on a fork I have of it on github. Links in previous posts on this thread. FW can look at it, and choose to include it if they wish. It fixes all the edge cases I am aware of.
If FW wish, they can send me examples of other FW laptops, on which I would be happy to test the code on, to see if my fixes, fix it across all the FW laptop variants.
Caveat: my fixes are only in the area of Normal, Idle, Discharge state changes. I have not looked into, or changed the more low level charging current control functions because I don’t have the datasheets for the batteries. So, I cannot evaluate if that part is being done correctly in the EC code. From looking at the source code, it does appear to be handling some of the more obvious edge cases with what looks like sensible behaviour.

3 Likes
268

I successfully flashed your EC firmware onto my FW13 with an AMD 7840U running Fedora 42. Thanks for the thorough documentation.

I built the ec image without issue once I tracked down the dnf equivalents to the required dependencies. I also compiled EcTool.efi using your instructions. I was unable to locate bootx64.efi, so I downloaded it directly from the following repo instead.

I couldn’t find a simple way to get write access to /boot/efi. Instead, I ran bootx64.efi and flashed the RW image from a thumb drive. I followed the instructions from the following link to do this, but I substituted in the ectool reflash --rw --yes command from your guide.

Here is the output from ectool after going through the entire process. The untouched R0 version in my case was the image from the 3.07 BIOS, it may be different for others.

sudo ectool version
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
RO version:    azalea_v3.4.113376-ec:55046b,os
RW version:    azalea_v3.4.113400-ec:ade951,os
Firmware copy: RW
Build info:    azalea_v3.4.113400-ec:ade951,os:48d761,cmsis:4aa3ff 2025-05-01 23:20:16 username@computer-name
Tool version:  0.0.1-isolate Apr 27 2025 none

The 80% charge limit I set in the BIOS is being respected so far even with battery extender enabled. Will continue to monitor.

While plugged in and at the charge limit, watch -n0.1 sudo ectool chargecontrol indicates the laptop is staying in idle mode as expected. Running watch -n0.1 "cat /sys/class/power_supply/BAT1/status" still reports the laptop as alternating between charging and discharging. I am unsure whether this reflects actual charging behavior in light of the ectool output. See below video for an example of this.

Would be happy to check other command outputs if it would be helpful. Thanks again for your work on this!

3 Likes
269

Hi,

It is great that you managed to install my EC firmware and it is working on your FW13 AMD 7840U

If you have managed to compile my version of ectool

sudo ectool chargecontrol3

Is a good one to use.
It shows more information specific to my ec firmware.
Also

sudo ectool sysinfo

And check it is running the RW one.

If it says RO, you might have skipped the EFi step after the flash step of:
ectool reboot
Boot into EFI again then
ectool reboot rw

It’s that last one that gets it to use the RW image.

If you power off the laptop and remove the PSU connection and leave for 2 mins it will revert to the RO image.

If you have it on the RW image, a laptop reboot or suspend will leave it on the RW image.

With the laptop in IDLE mode it means:
Power the laptop from the PSU connection, and use battery power if the laptop needs more than the PSU connection can supply.

If it is using both PSU and battery, the battery will say it is discharging.

Another output that would also be useful would be:

  1. sudo ectool battery
  2. sudo ectool batterytemp

We can then know what the current charge level is compared to the lower, upper and discharge limits.

Another thing to test is to disable the “battery extender” in the BIOS.
I have not tested with that enabled yet.

Which PSU / Power brick are you using? Make / Model.

1 Like
270

Awesome! What BIOS do you have?

271

For a bit of an explanation of the new “ectool chargecontrol3”

sudo ectool chargecontrol3 help
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
ERROR: Bad arguments

  Usage: chargecontrol3
    Get current settings.
  Usage: chargecontrol3 <slot> <lower> <upper> <discharge>
    Enable battery sustainer.
    <slot> == which of the 4 slots to adjust
    <lower> == the lower setting
    <upper> == the point to stop charging to
    <discharge> == the point to start discharging
    Use 255 if you mean -1
    between which EC tries to keep the battery level.
    Slot 0: Set by the BIOS
    Slot 1: This is the slot to use. It overrides whatever is in slot 0
    Slot 2: This is used by the battery extender stage 1
    Slot 3: This is used by the battery extender stage 2

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


sudo ectool chargecontrol3 1 30 80 255
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
sending chargecontrol3 1 30 80 -1

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

Notice that the “Battery sustainer slot = 1” meaning that it is taking the settings from slot 1, whereas before it was taking the settings from slot 0.
You might use the 30 - 80 % when playing a game, when you are happy for it to discharge during the game, but you don’t want it charging, and maybe causing the game to stutter.
Then after the game has stopped, you can either change the slot 1 settings again, or zero them out to review back to slot 0 which is the BIOS set values.

sudo ectool chargecontrol3 1 0 0 0 
interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
sending chargecontrol3 1 0 0 0

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

You can see it has reverted back to using slot 0.
Slots 2 and 3 are used by the battery extender, when it is active.

The third value is the discharge setting. Set it between the upper value and 100% if you want it to be used. A value of -1 or 0 means “Don’t use me, never force a discharge”.