After any esptool session, the S3's native USB considers a terminal
attached. If nothing drains the port, the firmware's serial log writes
block: boot stretches from ~5 s to ~5 min and BLE command responses
starve — indistinguishable from a firmware wedge from the outside. Also:
the USB re-enumerates as a NEW tty node after deep sleep, silently
breaking loggers that hold the old node.
Proposal: a bounded/non-blocking CDC log path (drop instead of block
when the endpoint backs up), and a docs note recommending stable
/dev/serial/by-id paths plus keeping a reader attached in dev setups.
Full diagnosis notes available (we ran this to ground on a PaperS3).
After any esptool session, the S3's native USB considers a terminal
attached. If nothing drains the port, the firmware's serial log writes
block: boot stretches from ~5 s to ~5 min and BLE command responses
starve — indistinguishable from a firmware wedge from the outside. Also:
the USB re-enumerates as a NEW tty node after deep sleep, silently
breaking loggers that hold the old node.
Proposal: a bounded/non-blocking CDC log path (drop instead of block
when the endpoint backs up), and a docs note recommending stable
/dev/serial/by-id paths plus keeping a reader attached in dev setups.
Full diagnosis notes available (we ran this to ground on a PaperS3).