I’m running into a cluster of related issues with the XIAO ESP32-C5 after flashing ESPHome (dev branch), and I’m hoping someone here has hit the same thing.
Note: I’ve reproduced this exact behavior (RTS reset failure + boot loop with zero USB enumeration) on two separate XIAO ESP32-C5 boards, so this doesn’t appear to be a defective unit — it looks like a software/config issue tied to ESPHome dev + ESP32-C5 rather than hardware.
Issue 1 — RTS reset stops working after flash
After the first ESPHome flash, the board’s USB port stops responding to the normal esptool/ESPHome auto-reset sequence (RTS/DTR toggling). No serial port shows up in the OS at all during normal operation. However, forcing bootloader mode manually (hold BOOT, tap RESET, release BOOT) does bring the port back — so it’s specifically the auto-reset-via-RTS that’s broken, not the USB hardware itself. This matches a report I found on esp32.com about esp32-c5 RTS reset failing when the primary console is USB Serial/JTAG with no secondary console enabled.
Issue 2 — Boot loop with zero USB enumeration
Separately, I’m now seeing a boot loop where the board resets continuously and there is no USB trace at all in dmesg/device manager — not even a flicker. This rules out a simple “logger silent but alive” situation; it looks like the USB Serial/JTAG controller itself never comes up during this loop.
What I’m trying next:
Since there’s zero USB enumeration, I’m planning to bypass the native USB Serial/JTAG entirely and go through the JTAG pads on the back of the board (MTDO/GPIO5, MTDI/GPIO3, MTCK/GPIO4, MTMS/GPIO2 + GND) using a J-Link probe with pogo pins, then OpenOCD + riscv32-esp-elf-gdb to catch the crash with reset halt.
Questions for the community:
Has anyone else seen this RTS-reset-broken behavior on ESP32-C5 with ESPHome dev, and is there a known fix/workaround beyond forcing a secondary UART console?
Since this reproduces identically across two boards, I’m fairly confident it’s not a hardware fault — has anyone identified what in the ESPHome dev / esp-idf combo for C5 causes this, or is it a known issue being tracked somewhere (esphome/esphome, espressif/esp-idf)?
Any pointers appreciated — happy to share full logs (via JTAG) once I get the probe connected.
There’s a useful follow-up in that esp32.com thread: the author links to ESP-IDF issue #18089. It reports C5 USB-reset problems with IDF 5.5.2 when USB Serial/JTAG is the primary console. UART as primary and USB as secondary worked for the reporter. The issue is now closed, but I’d check which fix your actual ESP-IDF revision contains; “ESPHome dev” alone doesn’t identify that.
One difference worth investigating: in the original forum report, the USB device remained enumerated. Your completely missing USB device could have an additional cause. No enumeration alone doesn’t establish a boot loop—how are you confirming the repeated resets?
Before connecting the J-Link, check the JTAG routing. Your GPIO2–5 mapping is correct, but the C5 defaults to routing JTAG through the built-in USB controller. Espressif’s external JTAG instructions describe the eFuse configuration needed to use those pads. Simply attaching the probe won’t switch it over, and eFuse changes are irreversible.
I’d first try capturing UART0 boot output with a 3.3 V USB-to-UART adapter. For application logging, ESPHome supports hardware_uart: UART0; its logger documentation lists C5 UART0 TX as GPIO10 and RX as GPIO11. Capture from reset, since the ROM reset reason and early boot messages may explain more than the application logs.
For your pogo-pin fixture, this PCBWay shared programming-adapter project provides an example of bringing signals out through spring contacts. You’d need to adapt the pad layout and connections for the C5/J-Link.
A minimal reproducing YAML, exact ESPHome commit, resolved ESP-IDF version and first boot messages would make a much stronger upstream report.
It is indeed a hardware issue, as users report that it works with hardware revision > 1.0.
This matches espressif/esp-idf#18089 exactly — setting the console to USB Serial/JTAG breaks the RTS-based reset on rev v1.0 chips specifically. Espressif confirmed the fix landed for chip revision v1.2 (production since ~May 2026 per their PCN), and a software workaround for v1.0 is still being backported into ESP-IDF (not yet merged for v1.0 chips as of this writing).
So to answer your question directly: I haven’t rolled back the BSP/config, since the config itself (board: esp32-c5-devkitc-1, variant: esp32c5, default logger:) is correct.
The issue is at the silicon level and reproduces identically on two separate boards regardless of config changes.
What arrangements have you made for users who purchase a faulty model?
PJ 