When the board tells you
nothing at all.
The ESP32 failures that cost the most time are not the ones with a stack trace. They are the silent ones: a board that resets forever, a peripheral that never appears, a single cryptic line repeating in the console. These are field notes on the ones we have actually lost days to.
Every article here started as a real bug on a real bench — usually one where the first four hypotheses were wrong, which is exactly the part that gets left out of most write-ups. So each one is organised around telling the causes apart rather than listing fixes: what the console actually prints in each case, which observation discriminates between them, and what to change once you know.
Three of the four below are boot loops. That is not an accident of our luck — the ESP32 has several failure modes that all present as "resets forever with no message," and the differences between them are a couple of characters in a reset-reason code. Being able to read that line is most of the skill.
None of this is specific to our tool. The chip IDs, flash offsets, pin tables and ESP-IDF settings apply to any ESP32 project, whether you write it by hand, generate it, or inherit it. Where our own tooling ended up solving something structurally — blocking a flash when the image targets a different chip, say — the article says so and explains the technique, because it is worth stealing rather than worth buying.
invalid header: 0xffffffff
The ROM loader is reading erased flash where your bootloader should be. Almost always an image built for a different ESP32 than the one you flashed it to — because the families boot from different offsets. How to confirm it in two commands, and how to recover.
Silent TG1WDT_SYS_RST loop on the S3
No panic, no backtrace, not one line of your own output. On an ESP32-S3 that usually means a hardware pin landed on the SPI flash or PSRAM bus — and the pins every ESP32 tutorial recommends, 25/26/27, are exactly the fatal ones.
Octal Flash Mode Enabled, forever
That line looks like the error and isn't — it prints on every healthy boot of an octal-flash board. The fault is an N16R8-class module built with the default quad settings, hanging in PSRAM init. Includes a part-number decoder.
USB camera returns no frame
Six causes in the order they actually bite: the camera on the UART port instead of USB-OTG, the console peripheral holding GPIO19/20, a control-transfer buffer too small for a webcam's descriptor, exact-match MJPEG negotiation, and a Full-Speed bus.