[SergioGasquez]

Recent full HIL runs fail intermittently on USB-Serial-JTAG targets. This PR makes the monitor survive a USB disconnect, removes a redundant reset before monitoring, and logs what the flash stub sent when its handshake fails.

Why

• ESP32-H4 and ESP32-P4 (usb): write-bin --monitor and flash --monitor fail with × Broken pipe right after the app prints cpu_start: Multicore app. The USB-Serial-JTAG device disappears from the host, and the monitor exits instead of waiting for it, so the test never sees Hello world!. This happened in 4 H4 runs (e.g. 40650085313). On the P4 it is tracked in ESP32-H4 and ESP32-P4: app drops off USB at startup #1101. It still happened with a 4 MB image in 40532392253, so --flash-size 4mb does not fully avoid it.
• Double reset: with a non-interactive monitor after flashing, espflash hard-resets the device after flashing, and the monitor resets it again about 300 ms later. Every log shows the first boot interrupted by the second reset.
• ESP32-C5 (usb): since Test flashing speed improvements #1060, board-info fails in about 4 of 14 runs with Invalid stub handshake response received (e.g. 40847569378). The error does not say what was received.

Changes

• monitor reopens its port after a BrokenPipe error, which is how serialport reports a vanished device on Linux and macOS (POLLHUP). It closes the port first, so the device can re-enumerate under the same name, then retries every 100 ms. CTRL+C exits while waiting in interactive mode. On Windows, a removed device reports other errors, so the behavior there is unchanged.
• flash and write-bin (and cargo espflash flash) skip the non-interactive monitor's reset when the device was already hard-reset after flashing over USB-Serial-JTAG. The monitor receives that boot's output at any baud rate. Over UART, the monitor still resets the device, so it gets the boot output at the monitor baud rate. --ram is unchanged.
• The bytes received in a failed stub handshake are logged at debug level, which HIL runs enable. The error type is unchanged.

This does not fix the cause of the USB drop in #1101. The monitor only survives it.

An AI tool generated a significant part of this change.

Testing

• cargo +nightly fmt --all -- --check, cargo clippy --workspace -- -D warnings, the CI feature checks with -D warnings, cargo test --lib and cargo test -p xtask pass.
• cargo check passes for x86_64-pc-windows-msvc and x86_64-unknown-linux-gnu.
• Not tested on hardware. The reconnect could not be simulated with a pseudo-terminal on macOS, because macOS ptys reject the baud-rate setting the monitor makes.

HIL: /hil full, since the monitor and reset paths affect every chip and both port types. The relevant jobs are esp32h4 | usb, esp32p4 | usb and esp32c5 | usb. Two jobs fail for unrelated hardware reasons: esp32 | uart (/dev/serial_ports/uart missing on its runner since at least 2026-10-07) and esp32p4 | usb (the board does not enter download mode in "Prepare device" and the runner has no UART for recovery) will keep failing until those boards are fixed.

[SergioGasquez]

/hil full

[github-actions]

Triggered full HIL for PR #1104.

Revision: c812b26f7a968707013f25b15c4c4f0d3801b9ab

Chips: all; suite: full

Run: https://github.com/esp-rs/espflash/actions/runs/40852832424

Status: ❌ HIL run failed (failure).