Serial attach resets ESP32 USB-Serial-JTAG chips (DTR cleared before RTS); P4 re-enumerates and the session dies #1617

Summary

Every serial attach to an ESP32 native USB-Serial-JTAG port resets the chip. On the ESP32-P4 that reset is CHIP_USB_UART_RESET, which also resets the USB PHY: the device re-enumerates, the session dies with Broken pipe about 4 s after opening, and FastLED autoresearch reports session closed and aborts. The C6 gets USB_UART_HPSYS instead, which keeps USB alive, so there the bug is a silent extra reboot per attach.

Cause

SerialManager opens the port (Linux asserts DTR=1, RTS=1 on open) and then applies the family idle state (false, false) by writing DTR first, then RTS (crates/fbuild-serial/src/manager.rs, both open sites):

(DTR,RTS) = (1,1) --DTR=false--> (0,1) --RTS=false--> (0,0)

(DTR=0, RTS=1) is the USB-Serial-JTAG "chip in reset" state, and releasing it reboots the chip. Writing RTS first passes through (1,0), which only sets the boot strap without resetting, and lands on the same (0,0) idle state.

Evidence (ESP32-P4, fbuild 2.5.30, Linux)

pyserial, same port, opened three times in a row, changing only the order in which the two lines are dropped after open:

rts-first -> no reboot (384 bytes)
dtr-first -> rebooted (745 bytes)    # ESP-ROM banner, rst:0x17 (CHIP_USB_UART_RESET)
rts-first -> no reboot (0 bytes)

Daemon log during bash autoresearch esp32p4 (each open is followed by a Broken pipe ~4 s later, i.e. the re-enumeration the reset triggers):

18:39:46.57 port opened successfully port="/dev/ttyACM2" ...
18:39:50.67 ERROR serial read error: Broken pipe port="/dev/ttyACM2"
18:39:51.19 port opened successfully ...
18:39:55.28 ERROR serial read error: Broken pipe ...

The kernel log shows the matching USB disconnect / re-enumeration for each one, and the node moved from ttyACM2 to ttyACM4 because the old node was still held.

Fix

Apply RTS before DTR at both open sites, and cover the order with a unit test using the existing control-line trait in esp_reset.rs.