When I opened the laptop up today (02.03.2025) it was again fully discharged.
On Friday I got an answer from Support asking me to provide images and information about my charger, RAM and SSD, also they asked me to remove the SSD for a day and check again.
Since I can’t trigger the fast drainage mode and it happens randomly, we cant be sure that just because nothing happend the error is gone and therefore due to the SSD.
As you can see in the table in my post the error can not occur for quite some time.
Also they wrote:
We also would like to inform you that it is normal for the main battery to lose 1-2% of charge per day because it needs to sustain power for the mainboard to keep the clock(time and date) updated. However, in your case, the battery being completely drained after a few days is not very normal.
Which to me feels disturbing for several reasons:
Most mainboards (even from Framework) are using a CR2032 battery for shutdown BIOS power supply. Such a battery has a capacity of about 235 mAh as you can see here for example. My framework laptop battery contains 3537 mAh according to the framework_tool, 1% of that is 35.37 mAh. This is the amount of discharge that is normal according to customer support. So a default CR2032 would last for 235/35.73 = 6.6 days. To me this doses not seem normal, especially since my other laptops don’t need to be recharged regularly.
It makes me loose trust in the customer support since calming a bug to be a feature is giving me no options and feels helpless to me.
I don’t want to own a laptop that I need to recharge every 2-3 weeks if I don’t use it.
EDIT 03.03.2025
The response from Support I got is this:
Can you please try a Live USB version of Ubuntu 24.04? No need to install it. Just run it through USB. Please check if the issue persists.
Its basically the same argument I had in the last E-Mail, which to me shows that they didn’t understood the problem, or my response for that matter.
Also they fully ignored my wish to refund the laptop if a 1-2% a day discharge rate is considered to be normal and therefore wont be fixed.
You know, I liked the idea of framework so much, and wanted to have one for the good cause, and now I feel like that was a mistake, and the idea is still good, but the complexity is too high for framework to manage, and I’m stuck with a device I can’t trust and a customer service that ignores me.
Today after battery was fully drained again, I swapped my old mainboard with the replacement board I got from framework. The replacement mainboard was packed in paper and cardboard, it didn’t looked like the paper is ESD protected, which feels wired for a technology company. As of now the new mainboard is working fine. I will keep you updated in case the fast drainage error occurs again, also I am going to monitor the daily battery drainage.
It was a long exhausting and unnecessary fight with customer support. In buying a framework laptop I also bought a platform to expand on and use for the next years, maybe even decades to come, but currently I’m not feeling that comfortable about being depended on a company which such a cumbersome customer support.
Since I swapped the mainboard, I didn’t had any fast battery drain incidents anymore. This looks promising to me.
On the 06.04.2025 I fully charged the battery and on the 20.04.2025 (so 14 days later) the battery had 72 % charge left as you can see here:
framework:~ # framework_tool --power -vv
AC is: not connected
Battery is: connected
Battery LFCC: 3900 mAh (Last Full Charge Capacity)
Battery Capacity: 2835 mAh
46.40 Wh
Charge level: 72%
Manufacturer: NVT
Model Number: FRANGWA
Serial Number: 0328
Battery Type: LION
Present Voltage: 16.240 V
Present Rate: 730 mA
Design Capacity: 3915 mAh
60.604 Wh
Design Voltage: 15.480 V
Cycle Count: 7
Battery discharging
I’m still not really happy with this fast battery drainage, but currently it also feels like i don’t have any options to change it. Unless further fast battery drains occur this topic is closed for me.
What were you doing with the laptop between 06 and 20 ?
Was it in standby mode ?
If you wish the battery to keep charge while not being used.
Power off the laptop, not standby.
Unplug the power cable.
After 2 mins, even the Embedded controller will switch off.
This has the best chance of retaining the battery life on a FW13.
The battery management on the FW13 is not great when it is active, and it is active:
while laptop has PSU connected, whether powered on or off.
while laptop is suspended, without or without PSU connected.
The best bet is to leave it in a state where it is not doing battery management, i.e. the EC is off.
“EC off” is achieved with laptop power off AND PSU disconnected.
I hope the work around will help for you for now.
The EC has a number of battery management related bugs.
I have modified my own EC source code so that the battery management bugs have been fixed for me on my FW16, but I don’t know how well or not they might work with a FW13 AMD.
I have a pending question out with FW support regarding the FW13 aspects.
As I described here I always use init 0 as root to shut the laptop down, so I’m pretty sure it was not in standby and completely shut down. I didn’t touched it during that time.
But if you have any other suggestions let me know, since to me this fast discharge behavior feels like a bug, as I described here with the CR2032 example. Of course customer support doesn’t seem to be caring much about the issue. If I get a chance to rectify this behavior I would actually be happy with the Framework since I’m not using it on a day-to-day basis
Yeah sorry, I was too ambiguous in my answer, I always store the laptop in a bag without any cables (also no power supply attached to it) and only one USB-C-Card in slot 1 installed.
I think the laptop might be going into suspend instead of powering off.
You can configure it not to wake up when you open the lid. This let’s you see whether it was suspended or not based on whether the power led is flashing slowly or not. You then press the power button to wake it.
I already did exactly that, and there was no Power LED blinking. I’m very sure the laptop is powered off. Customer Support tells me that the CMOS-clock is using up that much energy, I personally don’t believe that to be the only reason for the drainage.
Thank you for confirming this. (was not in standby).
My initial guess was that it is just buggy code in the EC.
See my long investigation here:
But, with the laptop powered off, and the PSU cable removed, the EC is not running, so even buggy code in the EC cannot affect this.
I guess there might be an edge case, say if the EC has set the laptop to “DISCHARGE” just before shutdown and not left it in “NORMAL” state.
My FW16 does not show the problems you are seeing with the FW13, so I don’t think I will be able to reproduce your problem.
If I had the FW schematic, I could probably find out if the “DISCHARGE” state continues even if powered off.
Lastly, what FW say about the CMOS-clock might be true. As in, although a CMOS clock only tends to draw about microwatt, maybe they have a circuit around that, that saps the power unnecessarily. But, that’s all speculation, without a FW schematic.
Customer support tells me that the slow discharge is normal, due to the CMOS-Clock. So I assume (and I believe I read it somewhere else in this forum) that I am not the only person with this issue in an AMD FW 13. Probably most people are using the laptop on a daily basis and therefore don’t run into this issue, that’s why it is lagging attention.
I did the math here:
which also feels wired to me, since my Desktop mainboard CR2032 lasts for several years, not days.
About your FW16: you can go ahead charge it up to a know value e.g. 90%, shut it off and leave it like that for 14 days and then see how much battery is left, then you know if it really does not has this problem.
I’m pretty sure I’ve had my FW 16 sit at least that long, as well as an 11th gen FW 13 with the CMOS battery eliminator board (so the main battery is powering the RTC circuit) and neither of them were at 0% after sitting, turned off, for two+ weeks.
Maybe a good metric to use here would be “battery percentage drop over 1 day” in my case that would be 90% - 75%/14days = 15%/14days ~ 1%/day.
So what would be interesting to me is how much the battery drained in your devices?
Every laptop from every company will experience some battery drainage, but the laptops I previously owned where draining way slower, more in the <10% in half a year.
If you want more accurate battery measurements do:
sudo ectool battery
Battery 0 info:
OEM name: NVT
Model number: FRANDBAT01
Chemistry : LION
Serial number: 0084
Design capacity: 5491 mAh
Last full charge: 5635 mAh
Design output voltage 15480 mV
Cycle count 79
Present voltage 15433 mV
Present current -732 mA
Remaining capacity 3113 mAh
Desired voltage 17800 mV
Desired current 5491 mA
Flags 0x06 BATT_PRESENT DISCHARGING
Battery level (%) = (Remaining capacity * 100) / Last full charge
So, for the above, the result is:
55.24 percent.
It showed 55 percent on the Gnome GUI panel for me.
So, you could do:
date >> before1
sudo ectool battery >>before1
switch off
hours later come back and do:
date >> after1
sudo ectool battery >>after1
and then work our exactly how much was lost between those two times and extrapolate it over a longer period.
I think leaving it overnight would be long enough, unless there is something else at play here, that only kicks in after days of non-use.
My FW 16 is currently at 61%. I just shut it off. I will do my best not to use it for two weeks and I will check the battery at that time and report back.
I use my 13" AMD too much to want it to sit for that long right now.
I have done some measurements over night. My measurements are on a FW16 AMD.
Laptop powered off and PSU disconnected.
Before switch off (from “ectool battery”:
Last full charge: 5635
Remaining capacity 4481
79.52 %
After a night switched off (8 Hours 5 mins 33 seconds later:
Last full charge: 5430
Remaining capacity 4314
79.44 %
Then a few hours later:
Last full charge: 5408
Remaining capacity 4333
80.12 %
So, it is actually very difficult to tell whether and how much charge is lost, because the battery BMS is re-calibrating. Here is re-calibrated and then actually reported an increase in charge. It was not actually being charged at all, it is just reporting it as having increased, when in reality, no more charge has been supplied.
But, it appears that maybe 0.08 % is lost overnight over 8 hours.
One probably needs to take more measurements, over many nights, in order to get a larger sample size and a more accurate figure.
Maybe 0.01% per hour, or about 43mAh each hour.
43mAh still seems a lot if all it needs to do is:
Keep power to the BBRAM or CMOS RAM.
Enough of the circuit alive to detect a power button press and wake the EC.
But it does seem to match what you were told from FW support.
Hi, I just had the same issue. Laptop shut down apr 27 23:30:09, turned it on apr 30 14:24:40 and the battery was completely flat. It was shutdown properly (I just checked the logs), no USBA port in the back, PSU disconnected. Could be the same issue?
On the first glace it sounds very similar to my problems. For me the fast discharge happened within the first month of owning the laptop, so if your device is fairly new, this could be another indicator of it being the same issue. If it is the same issue you need an replacement mainboard, that is the only thing that actually fixed my problem.
