Repository navigation
PD Related Issue on AMD platform #225
Description
This issue has been created to track and gather information related to PD issues we have seen reported to us on different AMD Mainboards across our different platforms. This includes;
Framework Laptop 13;
- AMD Ryzen™ 7040 Series (BIOS & Drivers page)
- AMD Ryzen™ AI 300 Series (BIOS & Drivers page)
Framework Laptop 16;
- AMD Ryzen™ 7040 Series (BIOS & Drivers page)
- AMD Ryzen™ AI 300 Series (BIOS & Drivers page)
Framework Desktop;
- AMD RYZEN™ AI Max 300 Series (BIOS & Drivers page)
Some of the issues we have seen reported (includes but is not limited to);
- USB Port 5 Lost on Framework Laptop 16 AMD Ryzen™ 7040 Series.
- TBT Device not working on AMD RYZEN™ AI Max 300 Series. (JHL7440 controller) on Framework Desktop.
- Network Disconnection when running sunshine service on port 4/5 on Framework Laptop 16 AMD Ryzen™ AI 300 Series.
- Specific Portable Type-C monitor cannot be displayed on Framework Desktop.
These issues are being investigated by us as well as our manufacturing partner Compal. If you believe the issues you are facing fall under this problem, please include the below requested information in a comment following the posted template. Depending on which Operating System you are using, the process may be different on how/ what information is gathered.
These issues do not include;
- Wi-Fi or Bluetooth loss when using high speed devices on the front right expansion card slot on the Framework Desktop, this is an issue related to signal integrity.
First, if you are having this issue, make sure that you are on the latest BIOS & Drivers. If you are not, you can go HERE to make sure you are up to date. This is required as any testing done by us or our manufacturing partners will be done on the latest BIOS & Drivers.
- You can also sign up for notifications of when our latest BIOS & Driver updates are available for your device. This way if an update is published, you can test if the behavior being faced is resolved, same, or different on the new BIOS.
Important if using Linux - Please use the CLI (command line) utility fwupdmgr to update your Framework Computer firmware. This will provide detailed information about what updates are being completed. In the unlikely event that anything goes wrong with firmware updates, using the CLI utility will also provide us with output messages that explain what happened and why.
- Updating instructions using fwupdmgr can be found on each respective release page: https://fr.mw/link/bios
- If you have any issues in performing this, please reach out to support: https://frame.work/support
If you are using Windows;
- Using framework_tool in Command Prompt (Ran as Administrator), run the
framework_tool --versionscommand.- Copy the output information into your comment.
- If you run into an error, make sure framework_tool is installed. You can follow the instructions in the above hyperlink to get it installed.
- You can also directly use the
winget install framework_tool --source wingetcommand in Command Prompt (Ran as Administrator) to install framework_tool.
- You can also directly use the
If you are using Linux;
- Firmware: (Output of
framework_tool --versions) - OS / Kernel: (Output of
uname -r) - DRM Status: [Paste output of
grep . /sys/class/drm/card*-*/status] - Use this to gather the requested logs;
- LOGS: (Link to
dmesgorjournalctl -b)
- LOGS: (Link to
- Output of
sudo framework_tool --pdportsandsudo framework_tool --pd-infowhile the failing peripheral is connected to the affected port.
General information we will be asking for;
- Behavior being experienced/ Issue:
- The device you are trying to connect to your Framework Laptop/ Desktop (Name and Model Number)
- If it includes a cable, is it the cable that came with the device, or a different one?
- If it is a different cable than what came with it, what cable is it? (Brand & Information)
- If you can include a link to where it was purchased from, or product page matching exactly what you have - it is additionally helpful.
- If it includes a cable, is it the cable that came with the device, or a different one?
- The Port/ Expansion Card Slot you are trying to connect it to.
- If you are not sure of the exact Port/ Slot number, you can check our page HERE.
- Which Expansion cards do you have in each slot?
- Does the device you are trying to connect work in other Port/ Expansion Card slots?
- If so, which ones does it work in & which ones does it not?
- Does the device work when plugged directly into the Mainboard (Expansion Card removed)?
- (For Laptop) Does the behavior change if you unplug the Laptop from the Power Adapter, have the device shut down for 3 or more minutes, plug the Power Adapter back into the Laptop, then turn it back on?
- When did the issue start occurring? (Date in YYYY/MM/DD format)
- Which BIOS version did it start occurring on?
- Did the behavior get better or worse when updating to a different BIOS?
- Detailed replication steps from beginning to end so our teams can try and replicate.
- If you wrote into support and have a case number, please include that case number.
- Any additional information you think would be helpful for investigating.
Please see below comment for Template to use for inputting your information into a comment;
To use the template, please follow these steps;
- Click "Issue Body Actions" in top right of the comment below
- Click "Copy Markdown"
- Paste info comment & fill out/ provide needed information.
- (Second comment will show an example of what the template would look like when filled in)
Activity
Iroh-Framework commentedon Jun 25, 2026
Behavior being experienced/ Issue:
framework_tool --versionsinfo:Windows Logs (if using Windows);
framework_tool --pdportswhile the failing peripheral is connected to the affected port.framework_tool --pd-infowhile the failing peripheral is connected to the affected port.Linux Logs (if using Linux):
uname -r)grep . /sys/class/drm/card*-*/status]dmesgorjournalctl -b)sudo framework_tool --pdportsandsudo framework_tool --pd-infowhile the failing peripheral is connected to the affected port.Device/ Item being connected to Framework Device (Name and Model Number) that is having issues:
Port/ Expansion Card Slot(s) issue is happening with:
Does or does not work in other Port/ Expansion Card slots?:
If so, which Port(s)/ Slot(s) does it work in & which ones does it not?:
Which Expansion cards do you have in each slot?
Does the device work when plugged directly into the Mainboard (Expansion Card removed)?
(For Laptop) Did the behavior change if you unplug the Laptop from the Power Adapter, have the device shut down for 3 or more minutes, plug the Power Adapter back into the Laptop, then turn it back on?
When did the issue start occurring? (Date in YYYY/MM/DD format):
Which BIOS version did it start occurring on?:
Did the behavior get better, worse, or same when updating to a different BIOS?:
If so, what was the BIOS version number before and after?:
Detailed replication steps from beginning to end so our teams can try and replicate:
Support Case Number (if you already have one):
Any Additional Information:
Iroh-Framework commentedon Jul 1, 2026
Example of Template filled in;
Behavior being experienced/ Issue:
framework_tool --versionsinfo:Tool Version: 0.6.4
OS Version: 10.0.0.26200
Mainboard Hardware
Type: Laptop 16 (AMD Ryzen AI 300 Series)
Revision: Unknown
UEFI BIOS
Version: 03.06
Release Date: 04/23/2026
EC Firmware
Build version: tulip-3.0.6-eb68558 2026-04-22 06:51:22 lotus@ip-172-26-3-226
Current image: RO
PD Controllers
PD 0: 0.0.22 (MainFw)
PD 1: 0.0.22 (MainFw)
PD 2: 0.0.22 (MainFw)
Intel Retimers (Potential)
Parade Retimers
dGPU: 83.0.0.5
Laptop Webcam Module (2nd Gen)
Firmware Version: 1.1.1
USB Hub RTL5432
Firmware Version: 0.0.7
Laptop 16 Keyboard Module - ANSI
Firmware Version: 0.3.1
Location: [ ] [X] [ ] [ ] [ ]
Touchpad
Firmware Version: v7E13
DisplayPort Expansion Card
Active Firmware: 101 (3.0.11.065, MainFw)
NVIDIA GPU
Name: NVIDIA GeForce RTX 5070 Laptop GPU
VBIOS Version: 98.06.3e.00.0a
Windows Logs (if using Windows);
Output of
framework_tool --pdportswhile the failing peripheral is connected to the affected port;USB-C Port 0:
PD Contract: No
Power Role: Sink
Data Role: Ufp
USB-C Port 1:
PD Contract: No
Power Role: Source
Data Role: Dfp
VCONN: Off
Negotiated: 5.000 V, 1500 mA, 7.500 W
CC Polarity: CC2
USB-C Port 2:
PD Contract: No
Power Role: Source
Data Role: Dfp
VCONN: Off
Negotiated: 5.000 V, 3000 mA, 15.0 W
CC Polarity: CC1
USB-C Port 3:
PD Contract: Yes
Power Role: Sink
Data Role: Dfp
VCONN: Off
Negotiated: 48.000 V, 5000 mA, 240.0 W
CC Polarity: CC1
Port Partner: Source
EPR: Active (Supported)
Sink Active: Yes
Output of
framework_tool --pd-infowhile the failing peripheral is connected to the affected port;Right / Ports 01
Silicon ID: 0x3580
Mode: MainFw
Flash Row Size: 256 B
Ports Enabled: 0, 1
Bootloader Version: Base: 3.6.0.009, App: 0.0.01
FW1 (Backup) Version: Base: 3.7.0.197, App: 0.0.22
FW2 (Main) Version: Base: 3.7.0.197, App: 0.0.22
Left / Ports 23
Silicon ID: 0x3580
Mode: MainFw
Flash Row Size: 256 B
Ports Enabled: 0, 1
Bootloader Version: Base: 3.6.0.009, App: 0.0.01
FW1 (Backup) Version: Base: 3.7.0.197, App: 0.0.22
FW2 (Main) Version: Base: 3.7.0.197, App: 0.0.22
Back
Silicon ID: 0x3581
Mode: MainFw
Flash Row Size: 256 B
Ports Enabled: 0
Bootloader Version: Base: 3.6.0.009, App: 0.0.01
FW1 (Backup) Version: Base: 3.7.0.197, App: 0.0.22
FW2 (Main) Version: Base: 3.7.0.197, App: 0.0.22
Linux Logs (if using Linux):
uname -r)grep . /sys/class/drm/card*-*/status]dmesgorjournalctl -b)sudo framework_tool --pdportsandsudo framework_tool --pd-infowhile the failing peripheral is connected to the affected port.Device/ Item being connected to Framework Device (Name and Model Number) that is having issues:
Port/ Expansion Card Slot(s) issue is happening with:
Does or does not work in other Port/ Expansion Card slots?:
If so, which Port(s)/ Slot(s) does it work in & which ones does it not?:
Which Expansion cards do you have in each slot?
Does the device work when plugged directly into the Mainboard (Expansion Card removed)?
(For Laptop) Did the behavior change if you unplug the Laptop from the Power Adapter, have the device shut down for 3 or more minutes, plug the Power Adapter back into the Laptop, then turn it back on?
When did the issue start occurring? (Date in YYYY/MM/DD format):
Which BIOS version did it start occurring on?:
Did the behavior get better, worse, or same when updating to a different BIOS?:
If so, what was the BIOS version number before and after?:
Detailed replication steps from beginning to end so our teams can try and replicate:
Support Case Number (if you already have one):
Any Additional Information:
GH4TP commentedon Jul 12, 2026
I've lost both USB-C ports AGAIN (i.e. they are inaccessible) and have submitted a document to support responding to questions in the template provide above
themkoi commentedon Jul 13, 2026
Should we provide the information here or to support? and does this include charging/epr problems? if yes I have provided most info in #192 and I could submit the full template in a few days since I need to upgrade the bios for tests and then downgrade again
GH4TP commentedon Jul 20, 2026
And they've vanished again
C:\Windows\System32>framework_tool --pdports
USB-C Port 0:
PD Contract: No
Power Role: Sink
Data Role: Ufp
USB-C Port 1:
PD Contract: No
Power Role: Sink
Data Role: Ufp
USB-C Port 2:
PD Contract: No
Power Role: Sink
Data Role: Ufp
C:\Windows\System32>framework_tool --pd-info
Right / Ports 01
Failed to read Silicon ID/Family
Left / Ports 23
Failed to read Silicon ID/Family
Back
Silicon ID: 0x30A0
Mode: MainFw
Flash Row Size: 128 B
Ports Enabled: 0, 1
Bootloader Version: Base: 3.3.63.001, App: 0.0.02
FW1 (Backup) Version: Base: 3.7.0.09F, App: 0.0.0E
FW2 (Main) Version: Base: 3.7.0.09F, App: 0.0.0E
themkoi commentedon Jul 26, 2026
I have finally got the time to update the bios same issue on 4.5 I attach the template in files since its 2 devices and its best to keep the logs seperate
aohi.md
baseus.md
HandyHat commentedon Jul 29, 2026
Behavior being experienced/issue:
framework_tool --versionsinfo:Windows Logs (if using Windows);
Output of
framework_tool --pdportswhile the failing peripheral is connected to the affected port.Output of
framework_tool --pd-infowhile the failing peripheral is connected to the affected port.Linux Logs (if using Linux):
uname -r)grep . /sys/class/drm/card*-*/status]dmesgorjournalctl -b)sudo framework_tool --pdportsandsudo framework_tool --pd-infowhile the failing peripheral is connected to the affected port.Device/ Item being connected to Framework Device (Name and Model Number) that is having issues:
I reproduced this issue on a variety of different power adapters, plugs and cables, as described fully in #205
Device/Cable 1:
Device/Cable 2:
Device/Cable 3:
Device/Cable 4:
Device/Cable 5:
Device/Cable 6:
Port/ Expansion Card Slot(s) issue is happening with:
Does or does not work in other Port/ Expansion Card slots?:
Which Expansion cards do you have in each slot?
Does the device work when plugged directly into the Mainboard (Expansion Card removed)?
(For Laptop) Did the behavior change if you unplug the Laptop from the Power Adapter, have the device shut down for 3 or more minutes, plug the Power Adapter back into the Laptop, then turn it back on?
When did the issue start occurring? (Date in YYYY/MM/DD format):
Which BIOS version did it start occurring on?:
Did the behavior get better, worse, or same when updating to a different BIOS?:
If so, what was the BIOS version number before and after?:
Detailed replication steps from beginning to end so our teams can try and replicate:
Support Case Number (if you already have one):
Any Additional Information:
HandyHat commentedon Jul 29, 2026
Behavior being experienced/issue:
framework_tool --versionsinfo:Windows Logs (if using Windows);
Output of
framework_tool --pdportswhile the failing peripheral is connected to the affected port.Output of
framework_tool --pd-infowhile the failing peripheral is connected to the affected port.Linux Logs (if using Linux):
uname -r)grep . /sys/class/drm/card*-*/status]dmesgorjournalctl -b)sudo framework_tool --pdportsandsudo framework_tool --pd-infowhile the failing peripheral is connected to the affected port.Device/ Item being connected to Framework Device (Name and Model Number) that is having issues:
Device:
Cable:
Port/ Expansion Card Slot(s) issue is happening with:
Does or does not work in other Port/ Expansion Card slots?:
Which Expansion cards do you have in each slot?
Does the device work when plugged directly into the Mainboard (Expansion Card removed)?
(For Laptop) Did the behavior change if you unplug the Laptop from the Power Adapter, have the device shut down for 3 or more minutes, plug the Power Adapter back into the Laptop, then turn it back on?
When did the issue start occurring? (Date in YYYY/MM/DD format):
Which BIOS version did it start occurring on?:
Did the behavior get better, worse, or same when updating to a different BIOS?:
If so, what was the BIOS version number before and after?:
Detailed replication steps from beginning to end so our teams can try and replicate:
Issue does not occur everytime.
Support Case Number (if you already have one):
Any Additional Information:
12 remaining items
GH4TP commentedon Sep 1, 2026
alvorithm commentedon Sep 7, 2026
Framework Laptop 13 (AMD Ryzen 7040 Series), Linux. Filled against the template above.
Behavior being experienced/ Issue:
AC on, and logsAC offone second later with the contract still in place. It never falls back to the adapter, so the laptop discharges with two sources attached.framework_tool --pd-reseton both controllers, and with the Expansion Cards removed and the devices plugged into the mainboard directly.framework_tool --versionsinfo:Windows Logs (if using Windows): not applicable, Linux only.
Linux Logs (if using Linux):
7.1.8+deb13-amd64(Debian 13; the fault also reproduces on7.1.3+deb13-amd64)/sys/class/typecdumps per port, the EC console log fromframework_tool --console followacross the whole plug matrix, and a timestamped plug log)sudo framework_tool --pdports: fails on this EC build, before and after every reset, so I cannot supply the port table:sudo framework_tool --pd-info, with the failing monitor on port 1:sudo framework_tool --power, monitor on port 1, contract present, nothing drawn:Chg Input Currentis 90 % of the selected PDO's current, so 4500 mA names the monitor's 20 V 5 A contract as the selected source whileAC is: not connected.EC console during the failing plug (`framework_tool --console follow`; EC port index 3 is port 1, 0 is port 3, 1 is port 4)
The last line is the discriminator: the contract stands, the charger is programmed, and AC goes off a second later. On ports 3 and 4 the same sequence holds and charging continues.
cypd_cfet_vbus_control:N fail:5also appears on plugs that charge (the port 4 reattach at 10957.678 charges right after one), so I am not claiming that line as the fault. Every contract change, on working ports too, logsTODO Implement pd_set_new_power_request port N.Kernel lines at every attach (nothing at all at any contract drop)
Device/ Item being connected to Framework Device (Name and Model Number) that is having issues:
Port/ Expansion Card Slot(s) issue is happening with:
Does or does not work in other Port/ Expansion Card slots?:
If so, which Port(s)/ Slot(s) does it work in & which ones does it not?:
Which Expansion cards do you have in each slot?
Does the device work when plugged directly into the Mainboard (Expansion Card removed)?
(For Laptop) Did the behavior change if you unplug the Laptop from the Power Adapter, have the device shut down for 3 or more minutes, plug the Power Adapter back into the Laptop, then turn it back on?
dce_aux_transfer_rawAUX timeouts, and it changed nothing about charging on port 1.When did the issue start occurring? (Date in YYYY/MM/DD format):
Which BIOS version did it start occurring on?:
Did the behavior get better, worse, or same when updating to a different BIOS?:
If so, what was the BIOS version number before and after?:
Detailed replication steps from beginning to end so our teams can try and replicate:
/sys/class/typec/port3shows the partner and its 20 V 5 A capability, and the battery discharges.framework_tool --powerreadsAC is: not connectedwithChg Input Current: 4500mA.Support Case Number (if you already have one):
ER2DV2X0(the report),IRMFEDKN(photographs and videos, since the form takes no attachments: two boot-menu photographs showing the charge LED dark on port 1 and lit on port 4, and two videos of the 60 W adapter entering port 1, one per plug orientation, where the LED lights for one orientation only)Any Additional Information:
journalctlalone hides this fault.framework_tool --pdportsfailing withInvalidCommandon this EC build means Linux users on 03.18 cannot supply the port table this template asks for.--pd-info,--power, and--consoleall work.GH4TP commentedon Sep 10, 2026
Were you sending me a test BIOS @quinchou77 ? I haven't received any code or comms from Framework Support on the topic as of today.
GH4TP commentedon Sep 23, 2026
Sadly I've lost my USB-C ports again
GH4TP commentedon Sep 23, 2026
After a cold reboot
BPMOmega commentedon Sep 24, 2026
Wanted to update this that I had experienced this same issue now with Port 4 a few days ago, which I usually have my power adapter plugged into. One day when I had turned my Laptop 16 on, I noticed a few hours later that the battery had drained down to under 20%. I checked the power adapter to see if there were any issues with it, and noticed it was completely cold (so it wasn't even running). I then plugged the power adapter into Port 1, and the battery started charging again.
While in this state, nothing plugged into Port 4 (USB drives, game controllers, etc) would be recognized, even if plugged directly into the port without using an Expansion Card. Powering the laptop off, waiting a few minutes, and then powering back on while disconnected from the power adapter and Port 4 worked again.
No hardware charges since then, but current OS details:
Edition Windows 11 Pro
Version 25H2
Installed on 06/22/26
OS build 26200.9550
Experience Windows Feature Experience Pack 1000.26100.372.0
taylanpince commentedon Oct 10, 2026
LG UltraFine 27MD5KL fails before Thunderbolt discovery on Laptop 13 AI 300, BIOS 04.02
Could engineering assess whether this reproduction matches the PD compatibility work discussed in this issue, and whether a model-specific fix or further diagnostic is available?
Hardware / firmware
lilac-4.0.2-fdbf549; both left/right PD controllers running MainFw 0.0.21. Read with framework_tool 0.6.2,--driver cros-ec --versions,--pdports,--pd-info.Reproduced on two Linux environments
Both Thunderbolt host routers enumerate. Internal eDP works. LG USB2 hub
043e:9a61appears briefly, then disconnects; downstream043e:9a73sometimes enumerates before dropping. Both environments log UCSI GET_PDOS failures andunknown error 256.The last Fedora left-rear trace records port3 partner add/remove/add at 677.600 / 678.638 / 678.780 seconds after boot, LG hub discovery at 679.010, disconnect at 679.515, and UCSI error256 at 679.960. Settled port3 reports a debug accessory, zero alternate modes, no advertised PD support. UCSI reports 5 V / 0 A, explicitly Not charging on Fedora; battery remains discharging.
The EC query on NixOS with LG through the rear-left module reports:
Completed controls / limitations
Does the older-peripheral PD fix described in the September update apply to Laptop 13 AI 300 / PD0.0.21 / LG27MD5KL? If a test BIOS is appropriate, please provide the exact model-specific package, verification details and rollback procedure. Otherwise, what targeted diagnostic or protocol-analyzer capture would help distinguish firmware compatibility from a shared Linux-driver problem? No experimental firmware has been installed. Full logs are retained locally; selected excerpts can be supplied.
quinchou77 commentedon Oct 12, 2026
Update on the Framework Laptop 16 Port 4/5 device drop issue:
We found the drops are caused by false RCP triggers on the PD controller. When VBUS dips slightly due to shared power rails, the PD controller's sensitive comparator fires an RCP event and drops the device.
Since we have a load switch on the board that can handle reverse current protection, we are planning to switch RCP monitoring over to the load switch instead of relying on the PD comparator.
GH4TP commentedon Oct 13, 2026
paolodeangelis commentedon Oct 16, 2026
Framework Laptop 13 Pro: USB-C display and charging disappear after resume
Behavior being experienced / issue
ucsi_acpiwhile the cable was connected immediately restored charging, DisplayPort Alt Mode, the monitor, and its USB hub:sudo modprobe -r ucsi_acpi && sudo modprobe ucsi_acpiframework_tool --versionsinfoCollected after recovery, with the monitor connected and working:
Additional hardware identification:
Laptop 13 (AMD Ryzen AI 300 Series)FRANMGCP09, revisionA9Linux logs
OS / kernel
DRM status
During the failure, only the internal
eDP-1display was connected; all external DP connectors were disconnected.After reloading
ucsi_acpi:The recovered external display is:
Relevant journal excerpt from the failure
While failed, Linux reported the AC adapter offline, the battery discharging, and the UCSI power supply at 0 V. The same boot also contains other
ucsi_acpi USBC000:00: unknown error 256messages, so this was not a single isolated log line.sudo framework_tool --pdportsCollected after recovery, with the monitor connected and working:
sudo framework_tool --pd-infoPower state after recovery
Device being connected
Port / Expansion Card slot affected
Right / Ports 01controller)Does it work in other ports / slots?
Which Expansion Cards are installed?
3.0.10.06A)Does the device work when plugged directly into the mainboard with the Expansion Card removed?
Did a full power-off for at least three minutes change the behavior?
ucsi_acpiwith the USB-C cable connected recovered the connection without rebooting.When did the issue start occurring?
Which BIOS version did it start occurring on?
Did updating BIOS change the behavior?
Detailed replication sequence
ucsi_acpi USBC000:00: unknown error 256.[drm] enabling link 3 failed: 15.sudo modprobe -r ucsi_acpi && sudo modprobe ucsi_acpi.Support case number
Additional information
ucsi_acpirecovered all three.unknown error 256appear related to Framework firmware tracker issue #225.TekuSP commentedon Oct 30, 2026
Behavior being experienced/ Issue:
framework_tool --versions info:
Windows Logs (if using Windows);
Output of framework_tool --pdports while the failing peripheral is connected to the affected port.
Output of framework_tool --pd-info while the failing peripheral is connected to the affected port.
Device being used: Touchpad
Port/ Expansion Card Slot(s) issue is happening with:
Does or does not work in other Port/ Expansion Card slots?:
Does the device work when plugged directly into the Mainboard (Expansion Card removed)?
(For Laptop) Did the behavior change if you unplug the Laptop from the Power Adapter, have the device shut down for 3 or more minutes, plug the Power Adapter back into the Laptop, then turn it back on?
When did the issue start occurring? (Date in YYYY/MM/DD format):
Which BIOS version did it start occurring on?:
Did the behavior get better, worse, or same when updating to a different BIOS?:
Detailed replication steps from beginning to end so our teams can try and replicate:
Support Case Number (if you already have one):
Case Number: I have long chat with support on email, but I cannot find case number
Any Additional Information: None
ebruhl commentedon Oct 31, 2026
I’m experiencing what appears to be the same charging issue described in #205 on my Framework Laptop 16.
Given that the laptop has no dedicated GPU and the issue occurs across multiple previously functional chargers, this seems more consistent with a USB-C Power Delivery or firmware problem than insufficient charger wattage.
I’m happy to provide additional diagnostics if helpful.
quinchou77 commentedon Nov 11, 2026
A quick update for each PD related issue.
We have identified the root cause of the issue; however, due to hardware design constraints, we are implementing a firmware workaround to address it. We are targeting this fix for the 4.06 release, scheduled for mid-December.
We have identified the root cause of the issue. The failure impacts not only the network interface but also USB Type-C devices in general, which can experience unexpected disconnections under specific conditions. We are targeting this fix for the 4.02 release, with the beta build scheduled for delivery later this week.
BPMOmega commentedon Nov 11, 2026
@quinchou77 That's great news to hear!
Now, how about the issue with the Graphics Module USB-C port, as I've reported here: #225 (comment)
I'd imagine it's a similar (if not identical) issue to what's been affecting the side ports. Do you know if this firmware update will also address that?
quinchou77 commentedon Nov 12, 2026
After re-reading your post, this looks very similar to an issue we recently resolved: Network Disconnection when running Sunshine service on Port 4/5 on the Framework Laptop 16 (AMD Ryzen™ AI 300 Series). This may happen on any type-c device.
Regardless of which device is connected to USB-C Port 4 or the dGPU port, both share the same voltage rail. Under certain loads, this causes the PD controller to falsely trigger a Reverse Current Protection (RCP) event even when no actual reverse current condition exists. We have a solution fix to prevent the PD controller from tripping RCP under this false condition.
I just post the beta release on community.
https://community.frame.work/t/framework-laptop-16-ryzen-ai300-bios-4-02-release-beta/86105