Shame the article didn’t also test mileage somewhere in the middle.
I suggest we all give up on this, due to the age of the issue everyone’s machine’s will be going out of warranty and framework will just tell us to buy a new mainboard like they did with me over another issue.
well it seems there may be a fix on the way… or a workaround:
It says “Fixes for battery extender functionality introduced in 3.06” but this issue has not been introduced in 3.06.
Installed the new bios, but the problem persists.
As soon as I enable boosting on the CPU (i5 1340P) via TLP, the flipping happens.
The only way to somewhat reliably mitigate it, is to disable CPU frequency boosting, in my case.
It really seems to be a power delivery problem. Either by the charging circuit or the power socket (although I tried all kinds of power adapters and cables).
Basically: for a short moment where the CPU boosts, the power draw of the CPU spikes as well, overwhelming the power circuit and discharging the battery for a brief moment.
I don’t know how other laptop manufacturers handle this. Maybe there’s a short grace period in the circuit where it doesn’t report a short battery draw? Maybe they have more capacitors, so it doesn’t need to draw from the battery?
I really think it’s down to a tiny power spike that can’t be handled gracefully from the power circuit
I did a series of stress test without battery. Here’s what I found. 7840U running Arch Linux, on Performance power profile.
When using a 30W power supply, you can boot into BIOS but that’s as far as you can get, attempting to continue booting to OS leads to immediate power cut. This behavior corresponds to:
When using a 60W power supply, the current is limited to 2700mA, however the power can only reach 33W, far from 54W. Both the instantaneous and sustained CPU power are 25W
readings
$ sudo ectool chargestate show
ac = 1
chg_voltage = 15400mV
chg_current = 0mA
chg_input_current = 2700mA
batt_state_of_charge = 0%
When using a 65W power supply, the current is limited to 2924mA, however the power can only reach 37W, far from 58.5W. Both the instantaneous and sustained CPU power are 28~30W
readings
$ sudo ectool chargestate show
ac = 1
chg_voltage = 15400mV
chg_current = 0mA
chg_input_current = 2924mA
batt_state_of_charge = 0%
This corresponds to
When using a 100W power supply, the current is limited to 4500mA, The power from USBC goes from 57W(still lower than 70+W in Performance mode) to 46W(the same as Performance mode with battery installed). The instantaneous CPU power is 45W(lower than battery installed 53W), the sustained CPU power is the same as battery installed, 35W.
Conclusion: For some reasons the presence of the battery itself enables higher utilization from the USBC input even when the battery is charged to 100% or the charging limit you set.
Battery is used for “stabilizing the grid”, if 30W charger is used, flipping when overall system load(NOT CPU load) <27W, discharging when overall system load >27W.
If 60/65W input, charging when <33/37W, flipping when 33/37W<overall system load<54/58.5W, discharging when >54/58.5W
If 100W input, charging when <57W, flipping when >57W, it’s not possible for overall system load to reach 90W
We can limit the CPU power to 25/29/45W when using 60/65/100W power supply to prevent the battery from flipping.
4 Likes
This problem is not related to BMS, but either EC or the topology of the computer’s hardware.
Here’s my guess:
Most “classic” laptops have one DC power input socket, 18~20V mostly 19.5V via DC5525. Said laptop can only be used with the AC adapter provided by the manufacturer, or if you have a bench power supply and you set the voltage/current correctly.
On these laptops, the power rail is connected directly to the 19.5V input. Then there are some DC-DC converters mounted on the 19.5V rail, to convert voltage to 5V, 3.3V, ~1V(VRMs) and of course, the battery.
The distinctive characteristic of these laptop, is all these AC adapters can provide power for maximum instantaneous load AND charging the battery with plenty(20%+) of headroom. In this case, the battery is merely a component of consuming power. Removing the battery does not affect the stability of the circuit. If the AC adapter is overloaded, it’ll turn off and the laptop runs solely on battery, hence the mandatory “headroom” of the AC adapter power rating. “Bypass charging” is inherent.
The problem with USB-C powered laptop is that to comply with PD standard, the laptop must be compatible with a variety of AC adapters with different power rating. To achieve that, a buck-boost DC-DC converter must be installed between the input and the power rail. This introduce a problem: non-instant response. When the load spikes, battery power is taken until the upstream DC-DC reacts, even if the load is lower than the input power rating.
For instance, you can draw up to 90W from a 100W input, with 45~75W load, charging the battery 45~15W, but you cannot draw more than 57W if the battery is removed, read the reply above for more information
There are bugs in BMS in random batches, like charging slowly below 25%, charging slowly below 21°C, only charge to 17.4V(should be 17.6V on 55Wh), discharging quickly below 25%, but they are not the cause of small charge/discharge cycle(see above). The reason is due to the lack of a direct connection to the power input, the laptop cannot use more than 33/37/57W with 60/65/100W adapter without using the battery as a buffer.
2 Likes
Do you have any source on bi-directional dc-dc converters ever being a thing on the battery? I have never seen that on a schematic and it also just sounds like a pretty silly thing to do.
Sorry, my guess can be mildly or wildly inaccurate, could you send some schematics so I (and other users) can improve the understanding of the power of the laptop?
As far as I know, I used two laptops that have both DC and USB inputs the DC input generates less heat, using the USB pd input makes the laptop hotter and have battery charging flipping behavior.
I could see manufacturers skipping the power-mux and charging dc-dc and using the newly required input dc-dc converter for battery charging on the usb-pd plattforms but that is hard to veryify even with schematics which we (mere mortals) don’t have for the frameworks.
On older platforms you either had fancy managed power mux chips down to unga bunga diode (or slightly less bunga ideal diode) muxing solutions, with those you could keep the input bus voltage way above the battery voltage so it realistically would never dip into battery as long as you don’t entirely overwhelm the power supply and they you’d want it to do that anyway XD.
1 Like
Bumping this cause some folks on the 3.08 BETA BIOS thread are reporting repeated battery plugged / battery unplugged notifications when battery is at charge limit.
I’d like to hear some official comment on this.
Whether it’s being investigated, whether cycling between charging / discharging as described here will damage the battery, etc…
Is there an issue in a public facing bug tracker I can follow?
Framework rightfully got critiqued for the pace of BIOS updates this past year and @nrp pledged to do better. Part of that is not letting threads like this just wither without updates
4 Likes
I’m on BIOS 3.07. I am on Arch Linux, running KDE Plasma 6.3.4. And my charging/discharging is flipping back and forth every few minutes since an update yesterday. It’s very annoying. I’ve been trying different chargers (official framework charger and others) and it happens with all my chargers. This wasn’t a problem a few days ago.
1 Like
I understand. A diode and a step-down DC-DC converter is connected in parallel between the DC bus and the battery. When the input voltage is higher i.e. 19.5V>17.8V, battery is charged by the DC-DC, when the input voltage is lower, battery powers the DC bus directly.
Same here on GNOME on Arch Linux. I haven’t tested downgrading upower so far, but I’m confident that it is Charge notification cycle on some laptops since 1.90.8 (#306) · Issues · upower / upower · GitLab.
3 Likes
That is a very old-school way to do it.
There are a lot of ways to do power muxing, on most semi modern laptops I have seen that was done using the charge controller. Here is a little overview from ti (not laptop speciffic).
While looking for active power mux chips I found this interresting nugget that may shed some light on what is going on. I have no idea what charge controller framework is using but it does sound like dipping into battery is a feature for some XD (see point 2.8 for example).
On further thought this dipping into battery thing being more common on newer devices is probably not from a single change but comes from multiple places, on one hand we have usb pd which requires both the charger and the laptop to do much more strict current limiting, having used laptop power bricks for other projects before I have observed them going quite a bit above rated output for quite a while without triggering over-current protection while most pd chargers I have quite strictly enforce the negotiated limits (which for the most part is not a bad thing but it does necessitate the device to also do current limiting on itself to avoid the charger disconnecting).
Then there is modern cpu/gpus just having much spikier power transients than they did a couple generations ago that likely also has an influence here, maybe just adding a lot more input capacitance on the vrm would help there XD. Have you tried kneecapping the short power limit to see if that helps? I am not surprised that me pushing 85W into the cpu for a few seconds till the cooler saturates would dip into the battery a little (especially with a 65W psu) but with stock settings it should not be that bad.
Also having the current limit enforced on the device does not allow you to dip into the output capacitance of the charger for transients anymore which may also be a factor.
2 Likes
Hot damn. I don’t want to speak too soon.. but I just downgraded upower to 1.90.7-1 and the cycling hasn’t happened (that I’m aware of) in the last hour or so.
Looking at the day I downloaded 1.90.8-1, it was 2025-03-31. This is around the time (maybe a day earlier than I remember) when the cycling started happening.
Downgrading upower is a decent short term fix, but man, that’s frustrating. Thank you @real_or_random for pointing this out. I would not have discovered it myself. 
2 Likes
@Matt_Hartley for visibility.
Presumably this bug will affect Framework’s officially supported distros if they upgrade their official upower packages to >=1.90.8 before this upower issue gets fixed? I had a quick look and I think Ubuntu 24.04 & Fedora 41 both ship earlier versions?
The GitLab discussion has some mention of the specifics of how Framework’s firmware handles charge thresholds & how that might affect how the the fix for the upower issue needs to be implemented. Maybe Framework engineers can share knowledge on the GitLab issue to ensure a solid fix?
Fedora 40 and Fedora 42 already got this 1.90.8 update of upower and it seems Fedora 41 package is still in testing.
But atleast it seems there are already fixes being worked on the gitlab issuse so hopefully this will get a new version soon.
I know the upower solution was just found but I wonder if anyone else who has been tracking the issue with upower and Framework knows how far back upower versions can go without having this issue? Would upower 1.90.2, for example have this issue, or is this a regression that only shows in 1.90.8?
This regression seems to be only in 1.90.8 so the previous .7 seems to be fine