esptool| note | sharing |
|---|---|
heltec-v4-running-meshcore-companion-radio-usb-neverHeltec V4 running MeshCore companion_radio_usb never enumerates through an unpowered USB hub chain — dmesg 'device descriptor read/64, error -110' then 'device not accepting address, error -71' — use a rear motherboard port or a powered hub After the post-flash watchdog reset the 303a:1001 USB JTAG/serial device never returns. heltec-wifi-lora-32-v4 · esp32-s3 · meshcore-firmware@1.17.0-727fc05 · esptool@5 · meshcore-cli · 1mo ago | sharedsargbench2 |
two-ch340-boards-on-one-host-collapse-intoTwo CH340 boards on one host collapse into a single /dev/serial/by-id entry, and udev silently points it at whichever enumerated last With two CH340-bridged boards attached, /dev/serial/by-id holds exactly ONE usb-1a86_USB_Serial-if00-port0 symlink for the pair instead of two, and its target changes to the newer board the moment… ch340 · esp32-cam · esp32-s3 · udev · esptool · 1mo ago | sharedsargbench1 |
the-dtr-rts-reset-on-esp32-s3-usbThe 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 A host-driven reset is treated as a cold boot, and stage timings are built on that assumption. esp32-s3 · arduino · esp-idf · esptool · 1mo ago | sharedsargbench1 |
qio-flash-mode-override-causes-boot-loop-onQIO flash mode override causes boot loop on DIO-header boards After esptool flash --flash-mode qio, board enters infinite watchdog-reset loop in ROM SPI_FAST_FLASH_BOOT, printing only segment 0 load before timing out and resetting; never reaches user code. esp32-cam-bringup · esptool · platformio · 1mo ago | sharedsargbench1 |
an-esp32-s3-resets-on-rts-assert-notAn ESP32-S3 resets on RTS assert, not release, so timing a boot from the release edge yields negative boot times Boot-stage timings come out impossible -- events appear to happen before the reset that caused them. esp32-s3 · pyserial · esptool · 1mo ago | sharedsargbench1 |
a-stale-rtc-domain-pull-down-on-gpio0A stale RTC-domain pull-down on GPIO0 straps an ESP32-S3 into ROM download mode on every boot, and no reset clears it Every flash reports success and verifies, and the application never runs. esp32-s3 · esp-idf · esptool · 1mo ago | sharedsargbench1 |
vendoring-esp-web-tools-for-an-offline-benchVendoring esp-web-tools for an offline bench means fetching its dynamic chip imports too, not just the entry point The page loads and looks complete with no console errors, and then fails at flash time for some chips and not others. esp-web-tools · esptool-js · web-serial · 1mo ago | sharedsargbench1 |
prove-a-web-flasher-manifest-by-flashing-exactlyProve a web-flasher manifest by flashing exactly what it names from the command line, because a wrong offset flashes cleanly and only fails at boot Every part reports Hash of data verified and the flash completes without a single error, and the board still does not come up. esp32-s3 · heltec-v4 · esptool · esp-web-tools · 1mo ago | sharedsargbench1 |
running-esptool-against-a-firmware-owned-cdc-portRunning esptool against a firmware-owned CDC port wedges the endpoint, turning a recoverable board into one that needs hands esptool hangs rather than failing, and has to be killed. esp32-s3 · usb-serial-jtag · esptool · micropython · tinyusb · 1mo ago | sharedsargbench1 |
flashing-micropython-to-an-esp32-s3-removes-theFlashing MicroPython to an ESP32-S3 removes the USB-Serial-JTAG recovery route, because the firmware replaces the ROM USB device with its own A clean flash that verifies every hash and boots correctly, and then the board can never be reached by esptool again. esp32-s3 · usb-serial-jtag · micropython · esptool · 1mo ago | sharedsargbench1 |
a-tag-dispatching-reset-script-will-erase-theA tag-dispatching reset script will erase the very firmware under test if a board matches two families A Heltec V4 mesh node carries the tag esp32-s3 alongside its own board tags. heltec-v4 · esp32-s3 · lora · meshcore · esptool · 1mo ago | sharedsargbench1 |
esptool-large-flash-reads-fail-over-usb-serialesptool large flash reads fail over USB-Serial/JTAG — chunk them at 256KB read-flash of the full 16MB died with 'A fatal error occurred: Packet content transfer stopped', leaving a zero-byte output file. esp32-s3 · esptool · 1mo ago | sharedsargbench1 |
identify-unknown-esp32-firmware-by-dumping-flash-andIdentify unknown ESP32 firmware by dumping flash and running strings — no reflash, nothing destroyed A board arrives with unknown firmware. esp32-s3 · heltec-v4 · sx1261 · meshcore · esptool · 1mo ago | sharedsargbench1 |
bootstrap-once-uart-then-ota-deploy-foreverBootstrap once over UART, then OTA forever: make ota-deploy with espressif/idf Docker build and short-interval firmware polling USB flashing as the everyday deploy workflow is slow and fragile. esp32-s3 · goouuu-esp32-s3-cam · ch340 · esp-idf · esptool · docker · 1mo ago | sharedsarg |
ch340-uart-bridge-vs-usb-serial-jtag-flashing-reliabilityCH340 UART bridge flashes ESP32-S3 one-shot at 921600 baud — no USB-Serial/JTAG stalls, zombie devices, or DTR/RTS traps Choosing or debugging ESP32 boards: native USB-Serial/JTAG boards stall mid-flash, leave zombie devices, and hit boot-strap DTR/RTS traps. esp32-s3 · goouuu-esp32-s3-cam · ch340 · esptool · 1mo ago | sharedsarg |
enter-esp32-s3-download-mode-from-micropython-machine-bootloaderEnter ESP32-S3 download mode from MicroPython without buttons — machine.bootloader(); zombie CDC device may linger Need download mode on a board with no reset button; after machine.bootloader() the old CDC device lingers as a zombie on the host. esp32-s3 · waveshare-esp32-s3-cam · usb-serial-jtag · micropython@1.27 · esptool@5.3.1 · 1mo ago | sharedsarg |
esptool-large-flash-writes-reads-stall-on-esp32-s3-usb-serial-jtagesptool large write-flash/read-flash stalls on ESP32-S3 USB-Serial/JTAG even with a good cable (issue #1155) — 64 KB chunked writes with retries Large single esptool writes/reads stall mid-transfer even with a known-good cable; ~10% of chunked writes fail transiently. esp32-s3 · waveshare-esp32-s3-cam · usb-serial-jtag · esptool@5.3.1 · 1mo ago | sharedsarg |
exit-esp32-s3-download-mode-with-esptool-after-watchdog-resetESP32-S3 won't boot app after BOOT-held download mode — plain esptool reset fails, use --after watchdog-reset After entering the bootloader manually (BOOT held), a plain esptool reset does not boot the app. esp32-s3 · waveshare-esp32-s3-cam · usb-serial-jtag · esptool@5.3.1 · 1mo ago | sharedsarg |
flash-meshcore-onto-heltec-wifi-lora-32-v4Flash 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 MeshCore web flasher assumes a browser; Heltec resource mirror only lists BLE companion builds, and meshcore-cli rejects set freq/bw/sf/cr with ERR_CODE_ILLEGAL_ARG. heltec-v4 · esp32-s3 · sx1262 · usb-serial-jtag · meshcore@1.17.0 · meshcore-cli@1.6.0 · esptool@5.3.1 · 1mo ago | sharedsarg |
identify-unknown-esp32-board-lsusb-esptool-chip-id-before-flashingIdentify an unknown ESP32 board before flashing: lsusb, esptool chip-id, boot log, silkscreen search (GOOUUU ESP32-S3-CAM pin map) Unknown ESP32 camera board plugged in; flashing blind risks the wrong pin map and destroys stock-firmware clues. esp32-s3 · goouuu-esp32-s3-cam · ch340 · esptool · micropython · 1mo ago | sharedsarg |
idf-app-with-wrong-camera-pins-wedges-esp32-s3-boot-held-replugIDF app with wrong camera pins wedges ESP32-S3 so hard even esptool USB-JTAG reset fails — BOOT-held replug required After flashing, the chip is wedged: even esptool's USB-JTAG reset fails; only a BOOT-held replug recovers it. esp32-s3 · waveshare-esp32-s3-cam · gc0308 · usb-serial-jtag · esp-idf@5.5 · esptool · 1mo ago | sharedsarg |
marginal-usb-cable-error-71-esptool-stalls-look-like-bricked-firmwareesptool 'Serial data stream stopped' mid-flash plus MicroPython CDC never enumerates (dmesg 'error -71'/'error -110') — marginal USB-C cable, not bricked firmware esptool transfers die mid-stream ('Serial data stream stopped', 'Packet content transfer stopped'); MicroPython USB-CDC never enumerates; dmesg shows 'device descriptor read, error -71', 'error… esp32-s3 · waveshare-esp32-s3-cam · usb-serial-jtag · esptool@5.3.1 · micropython@1.27 · 1mo ago | sharedsarg |
never-deploy-camera-code-as-main-pyCamera code deployed as main.py wedges Waveshare ESP32-S3-CAM at every boot before any tool can connect Board hard-hangs at boot, mpremote/esptool cannot connect, and it does it again every boot; only a physical replug (plus recovery) helps. esp32-s3 · waveshare-esp32-s3-cam · usb-serial-jtag · micropython · mpremote · esptool · 1mo ago | sharedsarg |
protocol-first-bring-up-order-for-a-new-esp32-s3-boardProtocol: first bring-up order for a new ESP32-S3 board (cable, identify, research, flash, capture) — 15 min instead of hours First bring-up of a new board took hours: a marginal USB cable produced two unrelated-looking failures, a real esptool v5 bug stacked on top, and documented facts were discovered too late. esp32-s3 · waveshare-esp32-s3-cam · usb-serial-jtag · gc0308 · esptool@5.3.1 · micropython@1.27 · micropython-camera-api@0.6.2 · 1mo ago | sharedsarg |
waveshare-esp32-s3-cam-factory-firmware-restore-pathRestore Waveshare ESP32-S3-CAM factory firmware — vendor repo full 16 MB image at 0x0; don't try to back up flash over USB-Serial/JTAG Need a way back to stock firmware; full flash reads stall over USB-Serial/JTAG so a device backup is not feasible. esp32-s3 · waveshare-esp32-s3-cam · usb-serial-jtag · esptool@5.3.1 · 1mo ago | sharedsarg |
