Hello. I know over-current faults are a known issue on 11th gen Intel Framework 13 laptops. But most forum posts and comments from Framework say either that they occur due to a low RTC battery, or due to inrush current spikes combined with a PD controller firmware bug (fixed in BIOS 3.04+) that didn’t properly debounce the over-current signal.
However, I think I’ve found a case where inrush current spikes are triggering over-current faults on the latest BIOS, 03.24.
Summary
I can reliably trigger USB over-current faults on my Framework 13 (11th Gen Intel) by attempting to flash an ESP32-C3 device using the ESPHome flashing website. This occurs on BIOS 03.24 (latest as of this writing), suggesting the debouncing fix in 3.04 doesn’t fully address the issue. The fault survives soft reboots but clears with a full mainboard reset. I ran into this while trying to flash an AirGradient ONE air quality monitor, which uses an Espressif ESP32-C3-MINI. Anecdotally, I encountered the same issue a few months ago when trying to flash ESP32-C3 devboards.
System Information
Model: Framework Laptop 13, 11th Gen Intel
CPU: i7-1165G7
BIOS: 03.24 (latest at the time of writing, version confirmed with sudo dmidecode -t bios)
OS: Debian GNU/Linux trixie/sid, Kernel 6.12.6
Desktop Environment: KDE Plasma 6.5.1
Browser: Chromium 131.0.6778.139
Battery: I’m using the 61Wh battery, although my laptop originally shipped with the 55Wh battery
Device Being Flashed
Device: AirGradient ONE (air quality monitor)
MCU: ESP32-C3 Mini with native USB-JTAG interface
Steps to Reproduce
- Start with a clean system state
- Validate that there are no over-current faults in the output of
sudo dmesg | grep -i current - Validate that no expansion cards are connected
- Validate that a known-working USB-A device, such as a wireless mouse dongle, works when connected with a known-working USB-A expansion card in a given port, e.g., the back-right port
- Validate that the USB-A device is enumerated, using
sudo dmesg -wandlsusb -t
- Validate that there are no over-current faults in the output of
- Connect known-working USB-A expansion card to the back-right port
- Connect AirGradient ONE via USB-A cable
- Verify that the AirGradient ONE enumerates normally as
ttyACM0 - Open Chromium, navigate to https://web.esphome.io/
- Click “CONNECT” and select “USB JTAG/serial debug unit (ttyACM0)”
- The device briefly appears, then disconnects and reconnects (with audible USB sounds on KDE Plasma)
- Repeat steps 6-7 two or three times
- On the final attempt, you hear a disconnect sound but NO reconnect sound
- Check dmesg - over-current faults are now present specifically for the ports on the side of the laptop that the USB-A expansion card is plugged into
Observed Behavior
After triggering, dmesg shows the over-current conditions for the appropriate side of the laptop:
$ sudo dmesg | grep -Ei current
[ 0.935809] microcode: Current revision: 0x000000bc
[ 1311.454458] usb usb3-port1: over-current condition
[ 1311.722457] usb usb3-port3: over-current condition
Additional symptoms:
- Right-side USB ports (port1, port3) stop enumerating any devices (confirmed via
dmesgandlsusb -t) - Left-side USB ports continue working normally
- USB-PD charging works on ALL ports at 60W (including faulted right-side ports)
- See
sudo timeout 5 cat /sys/kernel/debug/cros_ec/console_log | tail -100
- See
- Soft reboot (
shutdown -r now) does NOT clear the fault - Full mainboard reset (disconnect and reconnect main battery + RTC battery) DOES clear the fault
Key Observations
- The fault seems to be triggered during rapid reconnection cycles. I’ve noticed this with multiple Espressif boards. In the case of the AirGradient ONE, which uses the ESP32-C3-MINI, I think the web serial interface toggles DTR/RTS to reset the ESP32 into bootloader mode, causing rapid USB disconnect/reconnect events. The fault occurs after 2-3 of these cycles.
- When I first encountered this issue, I was able to fault the right ports first, then moved to the left ports and faulted those too. When I tried to reproduce this issue, I was only able to fault the right ports - the left ports successfully completed the flash without faulting. So it’s unfortunately a bit probabilistic.
- This is reproducible from a known-good state. I performed a full mainboard reset, verified no over-current faults, verified USB enumeration worked on all ports, then triggered the fault again within minutes.
- USB-PD and USB data are independently affected. EC logs show normal 60W USB-PD negotiation on all ports even when over-current faults are active. The fault only affects USB data enumeration.
- I’ve had boot issues because of a low RTC battery before (including having to charge with a non USB-PD, USB-A charger). But I replaced my RTC battery last year. I don’t think the RTC battery is at fault. My system clock is accurate and I’ve had my laptop powered on for several days. And I think my newish 61Wh battery is in good shape.
Hypothesis
The ESP32-C3’s native USB-JTAG interface has unusual power characteristics during the bootloader reset sequence. Each reconnection cycle likely causes an inrush current spike. The debouncing fix in BIOS 3.04 may have improved the situation, but the specific pattern of rapid sequential reconnects during web serial flashing still exceeds the protection threshold.
Possible Workaround
While I haven’t tried this, using a powered USB hub may prevent the fault, as the hub may absorb the inrush current rather than the laptop’s USB controller. If you’re working with Espressif boards specifically you might consider using a powered hub.
Attachments
I have full dmesg logs and EC console logs (USB-PD negotiation) available if useful.
Questions for Framework
- Is this a novel issue separate from the low RTC battery hardware bug?
- Is the over-current threshold or debounce timing tunable in the EC firmware?
- Is this a hardware bug or is it likely fixable in firmware/software?
- Is there diagnostic data I can capture during the fault trigger that would be useful?