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

interfaces:0xffffffff
comm_init_dev being used /dev/cros_ec
RO version:    hx30_v0.0.1-acd8c0b
RW version:    
Firmware copy: RO
Build info:    hx30_v0.0.1-acd8c0b 2024-11-27 14:30:19 runner@fv-az1709-652
Tool version:  0.0.1-isolate Apr 26 2025 none

FW13 Intel 13th Gen i5-1340P

1 Like

FW13 Ryzen 7840U, Fedora Linux, BIOS 3.07

$ 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.113376-ec:55046b,os
Firmware copy: RO
Build info:    azalea_v3.4.113376-ec:55046b,os:7b88e1,cmsis:4aa3ff 2025-02-18 03:37:44 lotus@ip-172-26-3-226
Tool version:  0.0.1-isolate Apr 27 2025 none

Hi.

I have put instructions on how to flash new EC firmware here.
The new EC firmware should fix the “Battery flipping” issue.

Please be aware that there is a risk that you could brick your laptop, with the only fix being sending it back to Framework.
Please only try it if you are sure.

DISCLAIMER of LIABILITY. The information provided is offered ‘as is’ and without any warranties, express or implied. I disclaim any and all liability for any actions taken based on the contents here.

It is a long process of downloading and compiling various tools.

Please let me know whether it works for you or not.

Link to instructions:

Note:
These instructions only work for “azalea” and “lotus” laptops. Essentially, it only works for FW13 AMD 7640U / 7840U and FW16 AMD 7840HS based laptops currently. It has not been tested and probably will not work on Intel based laptops.

FW13 Intel 11th Gen Intel Core: Firmware = hx20
FW13 Intel 12th Gen Intel Core: Firmware = hx30
FW13 Intel 13th Gen i5-1340P: Firmware = hx30
FW13 AMD Ryzen 7840U: Firmware = azalea
FW13 AMD Ryzen 5 7640U: Firmware = azalea
FW13 Intel Core Ultra Series 1: Firmware = marigold
FW13 AMD Ryzen™ AI 300 Series = lilac
FW16 AMD 7840HS: Firmware = lotus

This will tell you which version of EC firmware you have:

sudo ectool version

Note: lilac is a new one, and FW have not uploaded the EC firmware to github for it yet.

2 Likes

Thank you for your work. I have this CPU: AMD Ryzen 5 7640U. That CPU is not on your list. Yet, the firmware for my machine is ‘azalea’:

$ sudo ectool version
RO version:    azalea_v3.4.113353-ec:b4c1fb,os
RW version:    azalea_v3.4.113353-ec:b4c1fb,os
Firmware copy: RO
Build info:    azalea_v3.4.113353-ec:b4c1fb,os:7b88e1,cmsis:4aa3ff 2024-03-26 07:10:22 lotus@ip-172-26-3-226
Tool version:  0.0.1-isolate Apr 24 2024 none

The EC firmware for the 7640u would be the same as what a 7840u laptop would get, as they’re using the same EC for both motherboard models.

I have updated the message above to add 7640U.

Maybe using 7x40U and 7x40HS may be less confusing.

(Also just generally great work you are doing, the open source ec was one of the reasons I got a framework and jet I have not messed with it jet)

1 Like

Has anyone tried my EC firmware?
From a risk perspective:
My instructions try to ensure the new EC firmware is written only to the RW part and not the RO part of the flash.
If one succeeds in writing to the RW part of the flash, and leaves the RO part unchanged, it should not brick your laptop.
If you mistype my instructions and accidentally write to the RO part of the EC flash, it is not something I have tested, and it might brick your laptop. In all my experimentation, I only wrote to the RW part of the flash. I have never attempted to write to the RO part of the EC flash.

Maybe @Matt_Hartley or someone else from Framework could help out checking and testing the firmware

2 Likes

I am waiting to see if Framework has more communication about BIOS 3.08 first. They seem to think it would solve my issue. It’s been about a month since we’ve heard from them, so they ought to be giving us some kind of update soon.

I read over your instructions. They seem mostly straightforward. I might build a docker container to simplify the compilation steps, since they seem to be Debian-specific and I’m on Arch (probs a holdover from the Chromebook days :smiley: )

I’ve wanted to try out the firmware but I’ve not gotten around to installing Ubuntu. I use nobara primarily.

It should work on non-debian/ubuntu distros.
One might just need to modify the apt install steps to be dnf install commands instead.

If it helps, I could just upload the binary of the ec firmware, and then anyone could do the upgrade using the EFI shell, that works on both Windows and Linux because it uses the EFI shell environment before an OS loads.

1 Like

Regarding my fixes for the mini-cycles charge / idle / discharge bug in the EC. There has been no peep from FW as to whether they wish to include my changes or not.
I had an initial email thread open with them regarding one aspect, whether all FW main boards supported the IDLE state, they have been silent since then.
So, I have no idea whether or not they will actually really fix all the edge cases with their upcoming BIOS release.
Here are some of the edge cases:

  1. The battery BMS re-calibrates itself periodically. This can result in the charge % changing, thus trigger charge / idle / discharge cycles.
  2. Not all uses wish the battery to discharge with the AC PSU connected. So if the user changes the battery limit from 80% to 60% they don’t expect it to immediately discharge, whereas others do like that behavior. This should therefore be configurable.
  3. There is need for a hysteresis around the transition between IDLE and Normal (Charge).
  4. There is a need for a hysteresis around the Discharge / Idle. During charge there is a possibility for the charge of overshoot the battery limit %. It should switch to IDLE here, instead of immediately discharge back to the battery limit %. It add unnecessary charge/discharge cycles.
  5. The charge can skip the battery limit value, e.g. during a BMS re-calibration, and in this case, currently it just keeps charging up to 100%.

My EC fixes, cover all these edge cases by improving the battery sustain code to have 3 limits.
Limits are: lower, upper, discharge
SOC = Current charge %
State NORMAL (Charge if AC connected).
If SOC > upper, switch to IDLE.
if SOC > discharge, switch to DISCHARGE
State IDLE (Don’t try to charge, even if AC connected)
If SOC < lower, switch to NORMAL
if SOC > discharge, switch to DISCHARGE
State DISCHARGE (Discharge the battery, even if AC is connected)
if SOC < upper, switch to IDLE.
if SOC < lower, switch to NORMAL.

If the user does not wish to ever force the DISCHARGE state, they set the “discharge” limit to > 100%, e.g. 120%, so it can never be reached.

It is a very simple state machine, but covers all the edge cases well.

4 Likes

That’s really unfortunate. The fact that this is a “Community Forum” aside, it kind of seems like Framework really has no system set up for proper contributions to upstream, and given the debacle that is their firmware situation right now, I cannot see such a thing happening, even though if they did, the situation would improve drastically for folks. I want to assume best intentions on Framework’s part. Community contributions to the official firmware of the device would fill a very wide gap in their support.

Though that is becoming increasingly more difficult, especially given that last night support told me:

As much as we want to provide how many weeks, months it will take to release the BIOS update however, we still don’t have any update yet.

The Open Sourcing of their EC firmware is either virtue signaling, or a legal requirement. I seriously do not understand how this company cannot provide firmware support with relatively minor, low effort software patches, and yet was able to design and release TWO new products for this year.

And in the announcement video for the FW 12, they say they were working on the laptop for two years. You know what else took them almost two years? Publishing an LVFS update to enable TB4 on the FW 13 12th gen Intel ports

I know I’m just shouting into the wind at this point, but I feel Iike I got scammed. At this point, I have no other option than to assume this product, less than two years after I bought it, is no longer going to receive any software updates, and can’t in good conscience recommend people buy Framework products. I would very much like to have my mind changed, and the only thing that’s going to do that is if Framework actually allocates enough resources to bring the software support up to a standard deserving of the price tag.

2 Likes

ectool version
for an FW13 AMD Ryzen™ AI 300 Series:

RO version:    lilac-3.0.3-413f018
RW version:    lilac-3.0.3-413f018
Firmware copy: RO
Build info:    lilac-3.0.3-413f018 2025-03-06 05:45:28 marigold2@ip-172-26-3-226
Tool version:  0.0.1-isolate Nov 13 2024 none
1 Like

So you plan to release the binaries for Windows users as well? The work you’ve done is amazing but I won’t use it on my Debian install because I use Windows for gaming, where I need the full performance.
Amazing job by the way, Framework should definetly take notes…

Hi,

If you don’t wish to compile from source, but just install the binary EC firmware.
You can following these instructions (skip the compile step, but follow the rest):

It only works for FW13 AMD 7x40U (azalea) and FW16 7x40HS (lotus).

When flashing the firmware, look at the “go.nsh” and change the filename to “ec-azalea.bin” or “ec-lotus.bin” depending on which mainboard you have.
If you try to write a lotus one to a azalea mainboard, it will prevent you. It does a check that the EC firmware image is for the right mainboard.

This process will work on both Windows and Linux as the tools are EFI shell based, so work before an OS is booted.
Note: I don’t know where the EFI partition appears in Windows, so the file paths might need changing for Windows.

Example output, if you try to write a EC Firmware image to the wrong mainboard:

Safety: 1
*** BOARD MISMATCH ***
Current machine: lotus
Firmware image : azalea
3 Likes

Gentle reminder - we are curating from this only. Feel free to add your additional details and findings in the same post, but, we need these details otherwise we are fishing in the dark.

For us to track and address this, we need specifics. The initial gitlab post has “Arch Linux on a Framework laptop” which lacks critical information.

All affected, please provide, using this flow (please keep it short and to the flow below):

Framework Model:
(Please be specific; Framework Laptop 13 AMD Ryzen 7040 Series, Framework Laptop 16 AMD, Framework 13 , Framework Laptop 13 13th Gen Intel Core, etc - because this is a FW13 forum thread, likely only affecting FW13 folks, but we need details on which hardware is affected)

Distribution and release affected:
(Arch users, just provide the kernel used and the last time you updated)

Your upower version:
(This is the version you are running, after fully being updated with your packages and confirming the behavior still exists)

BIOS version:
(This means we expect you are fully up to date here)

Confirming yes or no you are using stock power management:
(Confirming there is no additional governor, TLP, etc is use - your running a stock configuration. For Arch users, you are using TuneD-PPD or PPD only.)

Power adapter used:
(Framework provided or if its yours own, we need brand, model and power specs)

Which expansion bay are you connected to for power:
(As this is for FW13 models, with the laptop facing you, please indicate if it is top left/ top right, bottom left/ bottom right.

I acknowledge this started out as FW13, Arch in this thread. But I suspect this may be affecting other platforms as well, hence the details above.

Please do not skip over any of these details, I need all of this to have something actionable to pass along to engineering. Thanks

@Jesse_Darnley for you to keep an eye on please, as folks populate these details, we can grab from this.

1 Like

Maybe you could forward the problems that @James3 found in the EC controller firmware, as this appears to be the root cause of a lot of the problems that upower has

1 Like