Blog
ESP32 Debugging: Core Dumps, Backtraces, and JTAG, Explained
The ESP32 crash you can’t read is the worst kind of crash. Here’s how to find the backtrace, clear the core dump partition, and figure out whether you actually need JTAG — usually you don’t.
My ESP32 crashed — where is the backtrace information in the ESP32 core dump?
Two places. The serial monitor prints a backtrace at panic — the “Backtrace:” block right after the “Guru Meditation Error” header. If the board rebooted first, the full dump may be in the core dump partition (IDF firmware only; Arduino sketches usually just print and die). Read it with espcoredump.py — the decoded output names the exact function that died.
How to Clear Core Dump Partition in ESP32?
For how to clear core dump partition in esp32, the reliable route is erasing it like any partition: esptool.py erase_region 0x8000 0x10000, or idf.py erase-flash if you don’t mind losing everything. It doesn’t hurt to leave it — the next crash overwrites the dump. People mostly clear it to silence storage warnings in ESP-IDF.
How do I read an ESP32 backtrace?
Copy the backtrace lines, run them through addr2line with your .elf file, and the addresses become file:line pairs. Arduino IDE hides this behind “Exception Decoder” in the Tools menu. The .elf lives in your build folder and must match the exact firmware that crashed — a stale .elf gives you plausible-looking nonsense.
What does a panic handler output mean?
“Guru Meditation Error” is stack overflow or bad memory access; “abort() was called” is an assert; a watchdog timeout is a task blocking too long. The header isn’t the important part — the function name at the top of the backtrace is. That’s your bug, ninety percent of the time.
How to Debug ESP32 PlatformIO?
If you searched how to debug esp32 platformio, the short version: set debug_tool = esp-builtin in platformio.ini, pick the adapter for your board, hit debug — breakpoints and watch variables work over the USB-JTAG bridge on newer chips. Older boards need a probe. The classic failure mode is forgetting DEBUG_LEVEL; without it, breakpoints land nowhere useful.
What is JTAG debugging, and do I need it?
JTAG is the full surgery: step through code line by line, inspect registers, halt the CPU. Most projects never need it — serial prints and backtraces cover the majority of bugs. It earns its keep on crashes that only happen at full speed, or when you’re writing bare-metal code. The honest answer: if you’re asking whether you need it, you probably don’t yet.
How to JTAG Debug ESP32 with FTDI Chip?
An FTDI FT2232H works as a JTAG adapter — wire TMS, TCK, TDI, TDO, and GND to the ESP32’s JTAG pins (GPIO12–15 on most boards), install OpenOCD, point it at the adapter. For how to jtag debug esp32 with ftdi chip: those pins can be remapped in firmware, which is how boards with the GPIOs in use still debug. Full wiring is in the KB.
Why does my ESP32 keep resetting?
Two causes show up constantly: the watchdog killing a blocked task, and power sagging during Wi-Fi transmits. Tell them apart by the reset reason on boot — brownout says power, task watchdog says code. Fix the supply first; it’s the cheaper guess.
What if my board won’t output anything at all?
Work the checklist: right COM port? Correct baud (115200)? Right board variant flashed? Port missing entirely is the driver question from the getting started FAQ. One trick that saves real time: hold BOOT at power-on — if the chip enters download mode, it’s alive and the problem is firmware, not dead silicon.
Where do I install OpenOCD for ESP32?
Don’t install stock OpenOCD — it lacks the ESP32 targets. Use the Espressif fork that ships with the ESP-IDF installer, or let PlatformIO’s toolchain fetch it automatically. Stock OpenOCD from apt is the #1 way to get “unknown target esp32” errors.
Debug It in the Tab Next to This One
Half of embedded debugging is proving where the failure is not. Two examples make that cheap:
- Serial echo — if
Echo: hellocomes back, your code path, monitor settings and TX/RX wiring are all sane. That eliminates three suspects in one line. - I2C scanner — before blaming a sensor driver, confirm the device answers at its address (
Device found at 0x27). No answer = wiring or power, not code.
The simulator adds what a bench cannot: reproducibility. Same sketch, same virtual board, same result every run — which is exactly the property you want when isolating a heisenbug.