If these were all off-brand chargers, I would (in part) agree.
However:
These are not exclusively “off-brand” chargers, but from reputable brands like Anker, UGREEN, Chicony, Belkin, etc.
I’ve tested and described the problem in detail in my top post as an issue with the laptop, not the charger, as the laptop pulls more current via PD than it has requested / is allowed to.
All of these chargers work to charge any other device (ones with 65W/100W maximum like the Framework as well), further confirming that it is an issue with the laptop, not the charger.
This has nothing to do with “cheap” or “off-brand” chargers.
All PD-compliant chargers with 20V and less than 65W, even from reputable suppliers, will not charge an AMD Framework laptop. In fact, the ones that do reliably work (again, with 20V and less than 65W) are probably more likely out-of-spec as they allow the Framework to pull more current than the Framework requests.
The issue affects ANY charger, regardless of whether you deem it as from a reputable/“off brand” manufacturer or not. Because it is the PD management in the Framework laptop which has the defect. And the list in that post has some very popular brands including Ugreen and Anker. From my side, I have the same issue with HP, Dell and Anker chargers. As well as a less-than-60W PD supply from a Lenovo dock.
Framework need to fix the PD management - if anything, the laptop overloading the charger and relying on the charger itself to limit current is a fire risk, especially for those brands that are “a nightmare under the hood”
It’s understandable that bugs can be frustrating, but this one is not that big, imho. The Framework charger works, and it seems some 65W chargers from other brands might as well. Unless I missed it, the issue is mainly trying to use lower wattage chargers.
Others have mentioned the time it’s taken for other BIOS updates. Framework is still a small team, under 50 people globally, spread over all the roles. Unfortunately, it will take time. As you say, Framework has responded.
If using a Framework charger is simply unacceptable, perhaps you can contact support and see if you can return your laptop.
We have tested the following fix on the Embedded controller:
Which will get into our next bios release.
What we were seeing is that low wattage 20V chargers will advertise PD 2.0 currents using resistor sensing of 3A. Eg 5V3A.
However when we negociate up to 20V, we need to reduce the input current limit on our charger to not go over the 20V current limit, eg 20V, 2A.
So when the charger voltage ramps up, the current would stay at 3A, and trip OCP on the charger.
Now when we transition to 20V, we will limit the input current on our charger.
Thank you Kieran, you are the best! Looking forward to install the fix on my AMD FW!
(Btw, my Intel FW has extremely good charger compatibility, it will charge with a potato if I want it to. So I assume the EC/PD on Intel FW is already programmed in this fashion?)
From what I can tell the intel mainboard uses a different PD controller (so has a different driver). I do however see a similar commit for the intel boards PD driver
Given the commit author (actually same person to author AMD board PD fix), it seems like Framework has had to go back to compal (the board manufacturer, and maybe partial designer? not sure what the full business relationship is there) to have this issue fixed. So that probably explains part of the delay.
Also this too for intel boards
Kieran seems to have done a lot of the work (or at least commit authored) the PD firmware for the intel boards
Many thanks @Kieran_Levin - very much appreciate the update and look forward to the BIOS update!
I can only speak for my use case (which is not that unusual for business users whom Framework now supports) - I need to use docks, both at home and at my workplace, which provide power at less than 60W. The issue is triggered and then the port seems to get into a state where it no longer functions reliably. I am hoping that is because the connected accessory cannot negotiate the PD correctly with the laptop and so this will all be resolved with the patch quoted above.
Long story short - I regularly end up with 1 or 2 ports that do not work and then I cannot charge the laptop at all.
One port for a dock, one port for a 65W charger. Preferably the Framework one.
Prior to USB-C charging, all laptops needed their own charger. And any very power demanding laptops still need this. The new high wattage PD will change this, but they aren’t yet available, last I looked.
Thank you for the fix, I’m really looking forward to the new firmware version!
There are, however also two issues with “dumb” 5V 3A chargers (10k pullups on CC lines):
starting charging does not work with those either, the laptop pulls 3A for 300-600ms, then just stops pulling anything (the “kickstart” workaround works to get it charging though)
when the voltage drops too low on the laptop-side (to ~4.6-4.7V), the current starts to oscillate wildly between 0 and 3A (see attached screenshot), possibly the laptop should reduce the current to a value where it can safely charge without oscillating.
Since the AMD does pretty much that with kickstarting(which for the most part seems to work around this overcurrent issue) it likely too will charge off a potato once this is fixed.
Not sure if this helps for diagnostic purposes. But it charged my FW13 AMD 7840u (prebuilt) without any apparent issue. I only have two expansion cards in at the moment. Win11 Home edition. Is there anything I can do to check if it’s charging improperly somehow?
If the current is below 4.75V, this is below the usb minimum voltage specification.
The current fluctuations could be caused by two things, either under-voltage protection kicking in on the PD controller, or more likely, the charger IC going below the AC present voltage threshold. However this is set to around 4.2V.
Generally I would suggest you use a charger that does not droop so much. Most chargers will output 5.1V or so to account for cable voltage droop.
We are working at refreshing the PD firmware to a newer sdk version in a later firmware update for the system, and we can investigate some of these additional issues at that time.
