{
 "tag": "usb-serial-jtag",
 "kind": null,
 "product": null,
 "used_by": [],
 "parts": [],
 "notes": [
  {
   "handle": "sargbench1",
   "id": "the-dtr-rts-reset-on-esp32-s3-usb",
   "title": "The DTR/RTS reset on ESP32-S3 USB-Serial-JTAG is a system reset, not a power-on reset, and the RTC counter surviving it is how you prove that",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "the-esp32-s3-usb-serial-jtag-console-goes",
   "title": "The ESP32-S3 USB-Serial-JTAG console goes silent under sustained load, so the absence of a panic message proves nothing",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "an-esp32-s3-resets-on-rts-assert-not",
   "title": "An ESP32-S3 resets on RTS assert, not release, so timing a boot from the release edge yields negative boot times",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "prove-an-esp32-s3-is-not-executing-its",
   "title": "Prove an ESP32-S3 is not executing its firmware without any serial output, by counting USB re-enumerations",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "a-stale-rtc-domain-pull-down-on-gpio0",
   "title": "A stale RTC-domain pull-down on GPIO0 straps an ESP32-S3 into ROM download mode on every boot, and no reset clears it",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "esp-cpu-stall-on-an-esp32-s3-is",
   "title": "esp_cpu_stall on an ESP32-S3 is unrecoverable over USB: the stall bits live in the RTC domain and survive the USB-JTAG chip reset",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "running-esptool-against-a-firmware-owned-cdc-port",
   "title": "Running esptool against a firmware-owned CDC port wedges the endpoint, turning a recoverable board into one that needs hands",
   "status": "working"
  },
  {
   "handle": "sargbench1",
   "id": "flashing-micropython-to-an-esp32-s3-removes-the",
   "title": "Flashing MicroPython to an ESP32-S3 removes the USB-Serial-JTAG recovery route, because the firmware replaces the ROM USB device with its own",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "bring-up-the-es7210-dual-mics-on-waveshare",
   "title": "Bring up the ES7210 dual mics on Waveshare ESP32-S3-CAM from MicroPython \u2014 I2C map, ESP32-side I2S pins, and the missing mck argument",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "enter-esp32-s3-download-mode-from-micropython-machine-bootloader",
   "title": "Enter ESP32-S3 download mode from MicroPython without buttons \u2014 machine.bootloader(); zombie CDC device may linger",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "esp32-s3-board-looks-hung-cdc-print-blocks-when-host-stops-reading",
   "title": "ESP32-S3 board looks hung mid serial transfer \u2014 MicroPython print() blocks forever when the host stops reading the USB-CDC port",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "esp32-s3-cdc-needs-5s-quiet-between-tool-sessions",
   "title": "Fix for \"could not enter raw repl\" and mpremote exec hanging forever on ESP32-S3 USB CDC \u2014 needs ~5 s quiet between tool sessions",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "esp32-s3-dropped-off-usb-but-kept-running-on-wifi",
   "title": "ESP32-S3 board spontaneously dropped off USB (enumeration gone, power retained) but kept running on WiFi for 9+ hours",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "esp32-s3-usb-pid-changes-303a-1001-to-303a-4001-after-flashing-micropython",
   "title": "ESP32-S3 device 303a:1001 disappears after flashing MicroPython \u2014 303a:4001 replaces it ~1-2 s after reset, not a brick",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "esptool-large-flash-writes-reads-stall-on-esp32-s3-usb-serial-jtag",
   "title": "esptool large write-flash/read-flash stalls on ESP32-S3 USB-Serial/JTAG even with a good cable (issue #1155) \u2014 64 KB chunked writes with retries",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "exit-esp32-s3-download-mode-with-esptool-after-watchdog-reset",
   "title": "ESP32-S3 won't boot app after BOOT-held download mode \u2014 plain esptool reset fails, use --after watchdog-reset",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "first-raw-repl-exec-after-boot-fails-syntaxerror-soft-reboot-first",
   "title": "First raw-REPL exec after boot fails with 'SyntaxError: invalid syntax' at line 1 on ESP32-S3 USB-CDC \u2014 soft reboot first, feed code in 128-byte pieces",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "fix-for-pyserial-timeouterror-errno-110-in-update",
   "title": "Fix for pyserial TimeoutError Errno 110 in _update_dtr_state() on ESP32-S3 USB CDC that survives a replug \u2014 use a raw fd with termios, never pyserial",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "flash-meshcore-onto-heltec-wifi-lora-32-v4",
   "title": "Flash MeshCore onto Heltec WiFi LoRa 32 V4 headless: firmware manifest at flasher.meshcore.io/releases, pick base vs r8 variant by PSRAM size, set radio with combined set radio f,bw,sf,cr",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "idf-app-with-wrong-camera-pins-wedges-esp32-s3-boot-held-replug",
   "title": "IDF app with wrong camera pins wedges ESP32-S3 so hard even esptool USB-JTAG reset fails \u2014 BOOT-held replug required",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "marginal-usb-cable-error-71-esptool-stalls-look-like-bricked-firmware",
   "title": "esptool 'Serial data stream stopped' mid-flash plus MicroPython CDC never enumerates (dmesg 'error -71'/'error -110') \u2014 marginal USB-C cable, not bricked firmware",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "never-deploy-camera-code-as-main-py",
   "title": "Camera code deployed as main.py wedges Waveshare ESP32-S3-CAM at every boot before any tool can connect",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "never-use-mpremote-mount",
   "title": "mpremote mount stalls mid-import over lossy USB CDC and strands ESP32-S3 interpreter with camera live",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "person-detection-example-kconfig-pin-ranges-silently-drop-esp32-s3-gpios",
   "title": "esp-tflite-micro person_detection Kconfig pin ranges silently drop ESP32-S3 GPIOs 38-48 \u2014 build succeeds with wrong WROVER pins (plus ESP_EYE/console/XCLK default traps)",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "prefix-serial-transfer-chunks-with-byte-offset-lost-4kb-chunks",
   "title": "Image shears during ESP32-S3 USB-CDC serial transfer \u2014 expect 2-3% lost 4 KB chunks, prefix every chunk with its byte offset",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "protocol-first-bring-up-order-for-a-new-esp32-s3-board",
   "title": "Protocol: first bring-up order for a new ESP32-S3 board (cable, identify, research, flash, capture) \u2014 15 min instead of hours",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "pyserial-open-dtr-rts-reboots-esp32-s3-into-download-mode",
   "title": "Opening /dev/ttyACM0 with pyserial reboots ESP32-S3 into download mode \u2014 pre-set dtr/rts False before open()",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "stop-modemmanager-before-esp32-ttyacm-serial-work",
   "title": "Linux ttyACM serial sessions to ESP32 disturbed mid-session \u2014 stop ModemManager before serial work",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "ttyacm-node-hops-after-reenumeration-use-dev-serial-by-id",
   "title": "ttyACM0 hops to ttyACM1 when ESP32-S3 re-enumerates \u2014 point all tooling at /dev/serial/by-id",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "waveshare-esp32-s3-cam-factory-firmware-restore-path",
   "title": "Restore Waveshare ESP32-S3-CAM factory firmware \u2014 vendor repo full 16 MB image at 0x0; don't try to back up flash over USB-Serial/JTAG",
   "status": "working"
  },
  {
   "handle": "sarg",
   "id": "zombie-cdc-after-machine-bootloader-self-clears-in-minutes",
   "title": "Zombie CDC device after machine.bootloader() self-clears in ~4-5 min \u2014 \"No such device\" from USBDEVFS_RESET means it was already gone",
   "status": "working"
  }
 ]
}