Blog
ESP32 Brick Recovery
Bricked-looking ESP32s are almost never bricked: the bootloader lives in ROM and survives almost anything you flash, so recovery is usually a reset, a reflash, or a two-button dance away. How to restart, what reboot loops mean, and how to bring a board back.
How to Restart ESP32?
Tap EN for a hardware restart, call ESP.restart() for a software one, or power-cycle for the hardest version. All three boot the chip fresh — boot ROM through WiFi reconnect. How to restart esp32 requires deleting nothing; it’s the gentlest recovery step and the right first move for odd behavior.
Why Does the ESP32 Keep Rebooting?
Three reasons cover nearly every loop: brownout (the supply sags under Wi-Fi’s ~300 mA transmit spikes), a watchdog firing, or firmware crashing at startup. The serial monitor names the culprit: “Brownout detector was triggered” is power, “rst:0xc” a software reset, “Guru Meditation Error” a crash. In my experience the answer to why does the esp32 keep rebooting is the power supply, and I check it before touching code.
How to Send a Command to ESP32 to Reboot?
esptool.py –port COM7 run resets the chip into normal boot over serial; MicroPython accepts machine.reset(). With a serial CLI, a custom “reboot” command is trivial. There is no universal reboot command in ROM — how to send a command to esp32 to reboot depends entirely on the firmware running, which official docs barely mention.
Is my ESP32 actually bricked?
Probably not. A chip that shows a COM port, answers esptool, or prints anything on serial is alive — only the flash content is broken. True bricking (a dead bootloader) is rare and usually needs a bad bootloader flash or hardware damage. Run esptool.py chip_id; a response means recovery is possible.
How do I recover an ESP32 that won’t boot?
Hold BOOT, tap EN, release — the chip lands in download mode even with garbage firmware, because download mode lives in ROM, not flash. Then erase and reflash known-good firmware. This works on every variant I’ve handled; the ESP32-C3 Super Mini is the odd one, lacking a labeled EN button, so check the silkscreen. The flashing guide has the erase-and-reflash sequence.
What do the rst: lines in the serial output mean?
They decode the reset reason: rst:0xc is a software reset, rst:0x10 an RTC watchdog, rst:0xf a brownout, rst:0x5 or 0x6 with “boot mode:3” a download-mode entry. The hex reads like gibberish until you learn the table — the debugging FAQ decodes all of it.
How do I restore the bootloader after a bad flash?
Erase the whole chip, then write a known-good image that includes the bootloader — factory binaries from Espressif, or a fresh Arduino or PlatformIO upload, both do this. IDE uploads always write the bootloader first, so erase + upload is the entire procedure. If the board boots afterwards, the bootloader was never broken.
How long does a reboot take?
A bare restart takes about 300 ms plus flash init; with WiFi connect, 1–3 seconds. Longer hangs usually mean waiting on something in setup — a slow sensor init, not the reset itself.
Does an ESP32 have a recovery mode like a phone?
No formal recovery menu exists. The closest thing is download mode, which lets a host erase and reflash anything — honestly, that’s all a phone’s recovery mode does. One button combination instead of a boot menu: recovery is erase plus reflash, full stop.
My ESP32 reboots mid-upload or right after upload — what now?
That’s a power problem, not a recovery problem: the USB port can’t deliver enough current, the board browns out during the erase-write cycle, and it restarts mid-operation. Use a better cable or feed 5V to VIN, then retry. If it reboots right after upload, it’s crashing in setup() — read serial instead of re-flashing blind.
A Place Where Bricking Is Impossible
Recovery is a hardware skill — and the best recovery is never needing it. The simulator is the safe room:
- Wi-Fi connect, HTTP server, a DOOM raycaster — flash any of them, crash any of them, mis-wire any of them. Refresh the page and the board is factory-new. No esptool, no download mode, no 3V3 panic.
Use it to separate “dangerous experiments” from “deliberate flashes”: prototype the weird stuff virtually, and reserve the real boot-button ritual from this FAQ for firmware that has already proven itself in the browser.