Framework 13 AMD original power adapter is insufficient

I have recently bought Framework 13 AMD Ryzen 7 7840U with the original power adapter 60w, I’m not doing any kind of overclocking or strange sorcery on the config of the turbo boost of the CPU but when I’m in heavy load (compiling software or something) I receive the message that the power supply is not powerful enough to power the device (see screenshot). My concern here is that this can degrade the battery over time.

  • Which OS (Operating System)
    A: Manjaro GNU/Linux
  • Which release of your OS:
    A: 6.8.5-1-MANJARO
  • Which Framework laptop
    A: Laptop 13 (AMD Ryzen 7040Series) (A7)
  • If this is a Linux issue, please use the Linux tag or at least put Linux in the title.
    A: Tag added, but is quite possible that Windows also have this issue

Can you confirm the draw externally by some means? With a kill-a-watt, a USB battery, or USB inline meter with a display, or even the Framework battery itself reading a discharge over time?

FWIW, I’m hard-pressed to get my (Ryzen 5 7640U mainboard) over 45W for the whole system, as indicated by powertop while on battery. Granted, it is just memory, NVMe, wireless, and one USB-C dock (all the other USB peripherals are externally powered). My usual PD source is 100W, but I rooted around for a 60W source, and was unable to reproduce the problem with that: the system charges the battery, albeit slowly, under as full a load as I could muster (intense 12-thread CPP build, 4k video playback). I confirmed with an 18W source that if I run my machine full-tilt, the battery is drawn upon (the system reporting ~30W draw on the battery, vs. ~44W with no power source).

My particular case is a permanent/non-mobile installation, so it may be of no help to you, but I’ve gone into the UEFI settings and configured them to limit the maximum battery charge to 60% specifically to try and take it easy on the battery. It’s essentially acting only as a glorified UPS in my scenario.

Long shot, but do you have any USB stuff that’s plugged in that might be drawing power? A phone, a dock, anything like that? USB A adapters in the rear ports?

Hi @Travis_Snoozy, thanks for the quick and detailed answer. Unfortunately, I don’t have a USB inline meter maybe I will buy one in the next few days… but from now I’m intrigued with this system… for example, With a script to measure the total power draw from the battery that looks like this:


while true; do
  echo - | awk "{printf \"%.2f\", \
  $(( \
    $(cat /sys/class/power_supply/BAT1/current_now) * \
    $(cat /sys/class/power_supply/BAT1/voltage_now) \
  )) / 1000000000000 }" ; echo ""
  sleep 0.5

Then I use this command to create a graph of the power consumption during a time period:

~/.scripts/ | gawk '{ printf("%.2f\n", $1); fflush();}' | ttyplot -s 80 -t "Total Powerfrom Battery [watts]" -u "whatts"

I put the power profile in performance (something that I didn’t have when the notification of insufficient power was triggered) and used the stress program to generate stress on the system with 16 threads of execution, the CPU goes to 100% of usage, then I get a max consumption of 51w see:

I also want to see from that total what amount of power will draw the CPU only so I use this:

sudo turbostat --Summary --quiet --show PkgWatt --interval 1 | gawk '{ printf("%.2f\n", $1); fflush();}' | ttyplot -s 80 -t "Turbostat - CPU Power [watts]" -u "whatts"

and I get a max power consumption from the CPU of 35w, see:

We have a difference of 16w that we can attribute to the rest of the machine…

So far so good we have not exceeded the 60w of the charger, but then I ran the same stress test with the computer connected to the power source. Now we can’t measure the total power consumption from the battery but we still can measure the power consumption from the CPU, and we have a peak of 55.2w of power consumption, see:

If we add 55.2w of the CPU usage plus the 16w of the consumption of the rest of the system we have a 71.2w of peak consumption. That is a lot more than the 60w that the power adapter can deliver. We have to take this measurements with a big grain of salt because I’m using max values and my methodology may not be the best but I will continue taking a look at this and if in the future I buy the USB-C inline meter I will put my findings here too. Thanks again and happy Sunday.

1 Like

I’m pretty sure this is due to the behavior of their EC and what it reports to acpi when you’re at 100%.

This is the same reason they say somewhere in their documentation that if you can’t get fwupd to offer you an update unplug for a few minutes and let the battery go down then plug in again and try again.

Tangentially, I’m running 3.05, which does include EC fixes – hence, why I could use the 45W (Steam deck) adapter that was hanging around.

Be careful with the BAT1 current * voltage, because I’m pretty sure that will flow in both directions, without changing sign. You’ll likely need to have another check against /sys/class/power_supply/BAT1/status to see if it’s Charging or Discharging, bearing in mind that there’s an inherent race condition because you can’t read all three values atomically.

[Edited to add]
Ah, I see, you weren’t checking the battery flow with the AC connected. Try doing so, and you should be able to build a graph that shows draw and charge when the system is in the nominal error condition – that is, validating that the battery is actually being dipped into and then topped back up, which is the wear concern.

I seem to have gotten a repro, albeit one that seems much smaller than yours.

I tweaked your script slightly to throw in a minus sign when discharging.


while true; do
   if [ "$(cat /sys/class/power_supply/BAT1/status)" == "Discharging" ] ; then
        echo -n "-"
   echo - | awk "{printf \"%.2f\", \
   $(( \
        $(cat /sys/class/power_supply/BAT1/current_now) * \
        $(cat /sys/class/power_supply/BAT1/voltage_now) \
    )) / 1000000000000 }" ; echo ""
    sleep 0.5

And I had to also change your command line slightly, to deal with the new scale…

~/.scripts/ | gawk '{ printf("%.2f\n", $1); fflush();}' | ttyplot -s 2 -M -2 -t "Total Powerfrom Battery [watts]" -u "watts"

But I’m definitely getting positive and negative values when running stress --cpu 12 and connected to a 60W PD source.

Switching over to the 100W charger, I saw only positive values (charging) until the battery was charged to my 60% limit, and then it stopped and held at 0, without showing negative (discharge) values.

You should check the values of /sys/kernel/debug/amd_pmf/current_power_limits with both chargers. The Framework EC does configure these differently based on different chargers connected and hopefully that’s illuminating to your above graphs.

Hmm; I do not seem to have that path. A quick look through my kernel config does not show that as having been compiled in. Guess it’s time to build a new kernel, reboot, and see what changes. :smiley:

This are the values that appears to me in /sys/kernel/debug/amd_pmf/current_power_limits I imagine that they are in milliwatts? where I can change that values? Maybe I add some very power hungry ram and nvme alongside the Ryzen 7 7840U… Thanks!

Also if I change the power profile to performance the values increase to:

OK – I think @Mario_Limonciello 's point is that when there is no external power there is a lower power ceiling…

spl:35000 fppt:35000 sppt:33000 sppt_apu_only:41000 stt_min:28000 stt[APU]:0 stt[HS2]: 0

Versus when plugged into a power source…

spl:51000 fppt:51000 sppt:33000 sppt_apu_only:41000 stt_min:28000 stt[APU]:0 stt[HS2]: 0

The value is the same for the 45W, 60W, and 100W supplies, once the system has settled. With the 18W supply, though, the power budget seems to be lowered…

spl:40000 fppt:40000 sppt:33000 sppt_apu_only:41000 stt_min:28000 stt[APU]:0 stt[HS2]: 0

Note that the spl number seems to goes down, the higher the load on the system is – so I’m assuming it represents the remaining budget. However, in the unplugged state, it won’t seem to go below 30800. When plugged in to AC power, it’s taken a long time, but it has driven down to under 30000. I’m not sure if it’s in some way related to the charge state of the battery raising back up to (in my case) 60% target or not.

I find it interesting that you have a higher spl listed than I do, @dario – my numbers are for a system that have /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference and /sys/devices/system/cpu/cpufreq/policy*/scaling_governor all set to “performance”, and I don’t see a change if I switch them to “power”/“powersave” (respectively).

Changing those files doesn’t change the coefficients.

This is why I suggest using PPD, it will change both EPP and ACPI platform profile, which changes the coefficients set by the EC by way of PMF.

I’m playing with a tool called RyzenAdj – which appears to be for setting these values that amd_pmf is reporting – and it looks like setting the sppt to 29000 (presumably, 29W) stops my system dipping into the battery when I’m running stress --cpu 12 and playing back a BlueRay.

I’m only seeing power-performance-daemon writing /sys/firmware/acpi/platform_profile because it’s choosing the platform profile driver on my system. Having skimmed the code and the logs, it seems that daemon will either change platform_profile, or energy_performance_preference, but not both at the same time. That said, changing platform_profile manually to “performance” is indeed giving me the same values as @dario reported, so this is still good information to have.

Hi @Travis_Snoozy, with the changes that you did to the scripts I can see that I have a deficiency of 4w with the power adapter. I tried a 65w and had no success maybe I buy a bigger one, but this is annoying and concerning…

With the power profile in performance is (~7w)

I believe that drain under high load is expected behavior for the power adapter. I will update here if I find the article.

I mean, one can view this in at least two ways…

Glass half empty: unit was sold with a power supply that doesn’t allow full performance, and is also not automatically throttling itself to stay within its power budget when powered by a 60W supply (at least, not by default on either of our not-actually-officially-supported Linux distros). The supply should have been a single USB-C 100W (20V, 5A) – the next step up in USB PD supplies after 60W (20V, 3A), and the throttling should have been set appropriately in firmware to prevent the battery from draining, at least in the 60W scenario.

Glass half full: unit has performance headroom very slightly above the closest USB PD match, and wasn’t artificially throttled to stay within that envelope, even though it could’ve been. For most normal operation, fits within the supplied power envelope fine, but in extreme cases can still keep up by dipping into the battery. Means are exposed to keep it throttled if not dipping into the battery is deemed more important than keeping that extra bit of performance in the extreme case.

Ironically, I got my 100W supply in anticipation of my FW16… but then opted for the 180W with that order, for fear of hitting this exact problem on that platform, leaving me to keep using this “overkill” one with my FW13. :sweat_smile:

It does change both at the same time, starting with 0.20 version.

Ah, that would explain it, I’m looking at the source for 0.13. Thank you, and sorry for the confusion.

I know that from an engineering standpoint, these kinds of calculations are hard, and maybe I won the silicon lottery and this chip can withdraw more power than it should during turbo, or maybe is the opposite and just withdraws more power just because of losses or deficiencies. But also it could be that the RAM and the NVME that I bought consume more than expected, so I’m not blaming Framework for anything. I’m just concerned about the battery because those popups appear not only when I’m doing a stress test, but quite often they appear during normal low-intensity work. I imagine that keeping that intermittency in the charging will make the battery swell in less than a year or two. I can spend the extra and buy a 100w adapter and leave the 60w for when I go out, just I hope that that solves the issue and not that for some reason the motherboard or something in between just doesn’t deliver the power. Thanks all for your support and ideas I’m just closing the laptop for today…

You can limit your max charge level to 80% (or a bit less) in the bios, and the battery will be quite fine for a very long time. A little bit of discharge+charge is not a full discharge cycle, just the fraction it is; but it is true that charge and discharge at the high and low end of the range of the capacity is more taxing/“damaging” than in the middle of the capacity. (For accurate capacity estimates you’ll need to do a full charge+discharge every once in a while, e.g. every couple of months.)