Gotcha, thanks 
By the way, are you documenting your process anywhere? Do you have code examples or instructions for flashing your EC? I donât have time myself to work on this right now but in case somebody else does now (or in the future!) it would be really valuable information 
Silly quesiton, how do I know which Port is which?
Which model do you have? I posted this earlier: This page will show you a guide for the AMD Ryzen 7040 board.
1 Like
Thank you @Will_Nilges.
@James3 - So far I have this problem on my AMD 7040 series 13 Laptop - Bios set to charge battery to 60%. It keeps flipping between charging and using battery. on Port 1. Testing Port 2 now. Will post results later.
Problem persists on Port 2. Iâm on Fedora Kernel 6.13.10-200.fc41.x86_64
Edit 1:
Framework Model:
Laptop 13 AMD 7640U
Distribution and release affected:
Fedora 41
Your upower version:
upower-1.90.8-1.fc41.x86_64
BIOS version:
3.07
Confirming yes or no you are using stock power management:
Yes
Power adapter used:
Framework 60W
Which expansion bay are you connected to for power:
Top left, bottom left
I have found what I think is the problem in the EC code.
Its the function:
sustain_switch_mode(enum ec_charge_control_mode mode)
It is broken logic in my opinion.
The problem is related to the decision points and state changes around the âsustain_soc.upperâ point.
It seems to ignore the fact that âint soc = charge_get_display_charge() / 10;â does not return a constant value when the battery re-calibrates itself.
The value returned will shift up and down slightly over time, thus randomly pushing the value into the âDISCHARGINGâ part. Thus causing the DISCHARGE - IDLE loops.
I am going to just remove the whole âDISCHARGINGâ state from that part of the code if the AC is on.
I have compared the charge cycles of the FW laptop to that of my mobile phone, and the mobile phone does not have the forced âDISCHARGINGâ state even if the AC is on either.
Its a bogus and unwise state to have in my opinion.
Also, one line even uses an (sustain_soc.upper == soc) to change state. That is also not a great idea. Comparisons should be >=, <=, > or < when comparing charge levels, == should never be used. That ==, in itself, can cause the battery to happily charge on up to 100%, skipping the sustain_soc.upper limit.
Oh wait, there is a whole different section of code that deals with charge limits. I will look at that tomorrow.
3 Likes
Thank you for all your work in investigating this.
With Upower version 1.90.6 on current kernel 6.13.10-200.fc41.x86_64 the issue seems to go away.
For another datapoint, I tested out my ThinkPad T14 Gen 3 (Also Arch KDE) and it looks like itâs sitting in a Fully Charged battery state from 88%-90%. My limit is set to 90%. The machine charged from 49% up to 89% and then stopped, and now itâs crept down to 88%. It also is capable of sitting at 80% Not Charging if I plug it in, so perhaps some extra trickery is going on.
Anyway, I think the Framework Laptop 13 is doing something wrong.
I had suspected earlier that the EC logic could be improved, see:
I agree that this code is hard to read. And itâs not entirely true what the ârightâ behavior should be. (What is the definition of
DISCHARGE?). The best you can do is to do what other laptops do.
edit: If youâre reasonably confident that the EC could be improved here, perhaps open an issue (or better, a PR) here: GitHub - FrameworkComputer/EmbeddedController: Embedded Controller firmware for the Framework Laptop
Just want to point out that AFAIK the upower 1.90.9 fix does not address the fact the battery alternates between Charging & Discharging (visible with watch -n1 "cat /sys/class/power_supply/BAT1/status" ) on the Framework 13 AMD once the battery limit has been reached. With the offical Framework charger, in top-left port in my case.
The upower 1.90.9 fix only addresses the problem that upower would decide that the AC adapter was unplugged if the battery was in a discharging state for a little bit, so youâd hear the OS chime notification, switch power modes, etc⌠And then it would think AC was re-plugged in once the battery switched back to Charging state, OS chime again, back and forth
The alternating between charging & discharging still happens ⌠but upower 1.90.9 simply no longer interprets that as AC power disconnect & reconnect.
I would like to understand from Framework staff if this discharging/charging flapping is expected as a result of their charging logic.
(Reposted from the 3.08 Beta thread because folks are talking about the same thing there. Sorry for reposting but I think it was pertinent to avoid confusion)
2 Likes
Another question, if you know: Does this have anything to do with the fact that my battery health floats around 87-90% all the time? It changes more frequently than any other computer Iâve ever owned.
I have been playing with the EC battery management code.
I have disabled it from using the DISCHARGE state while AC on.
If it wishes to use DISCHARGE, I have replaced that with IDLE.
I have found another edge case / bug now where it oscillates around NORMAL (this means charging if on AC) and IDLE (not charging). Not as damaging as the cycling discharge state, but it just means it takes far longer to charge. So, I have some more work to do to get it working how I wish.
1 Like
Nice! What needs to happen in order to get this out to the rest of the community? Would this be (yet another) BIOS update 
?
1 Like
Something I found along the way.
I donât know if anyone is playing with âectool chargecontrolâ, but there is an edge case that sends the EC into a charge/discharge loop.
So, my advice is to avoid âectool chargecontrolâ until either ectool is updated, of some other tool is used instead.
Summary, one needs an ectool that supports version 3 of the chargecontrol API.
I have so far fixed 3 bugs in the EC code battery control.
There are two remaining edge cases / bugs I need to track down.
Once I think I have found them all, I will publish the changes to the EC source code to github.
Hopefully, FW might then take a look at them, and choose to include them.
2 Likes
ectool chargecurrentlimit 0 can be a useful alternative for turning off charging. Use ectool chargecurrentlimit 4294967295 to remove the limit again.
Can I ask how you test these changes? I considered working on the EC code in the past, but I donât want to break my laptop that I need every day, and I donât know whatâs the simplest or safest way to update the EC.
I think I have it fixed now.
I have not seen any state cycling (flipping every few seconds) in various tests now.
No new bugs have shown themselves.
I will watch it for a few days, to check if anything else comes up, but it is looking pretty good right now.
Maybe at the weekend, I will get round to writing up what I have found on a wiki somewhere, with instructions on how other people can safely try EC code.
2 Likes
Mine certainly does the bing-bong with the charger in ports 1 & 2 on my FL16, Fedora 41, kernel 6.13.9-200
1 Like
You wouldnât want to do this on an FL16 when gaming as it will go into discharge mode when the power supply doesnât have enough capacity.
I imagine a similar situation can exist on an FL13 as well.
âDISCHARGEâ state while AC plugged in:
This essentially disconnects the AC power, and runs / discharges the battery.
Definitely not a good mode for games.
I am assuming it is disconnecting the AC power, because it discharges quite quickly, even when the laptop is idle.
When I plug my FW13 in to charge I get a consistent charge/discharge notification sound and wonât stop until I unplug the charge cable. Itâs hard to describe so I uploaded a video of it here: Proton Drive
If anyone knows what is causing this I would love to hear all about it.