Docs  /  When it doesn't work

Your Serial Monitor shows garbage or a crash dump — here's how to actually read it

You upload a sketch, open Serial Monitor, and the board resets every few seconds — sometimes with a wall of boxes and symbols, sometimes with a repeating block of text you don't recognize. The upload succeeded. Nothing in the IDE says anything is wrong. It just won't stay running.

What you're seeing

There are really only three patterns, and Serial Monitor is already telling you which one — you just have to read it in the right order.

Garbled text — boxes, random symbols, no readable words at all.

A repeating crash block — text containing Guru Meditation Error, Core 0 panic'ed, or a line of hex addresses starting with Backtrace:.

Clean boot messages repeating in a loop, no crash text — the board restarts but Serial Monitor never shows anything resembling an error.

Why it happens

Each pattern above has a genuinely different cause, and mixing them up wastes the most time.

Garbled text almost always means your Serial Monitor's baud rate doesn't match the rate your sketch set with Serial.begin(...). It looks like a crash. It isn't one — it's a settings mismatch, and it's the first thing to rule out.

A Guru Meditation block is a real firmware crash — the chip hit something it couldn't recover from (a null pointer, an array read past its end, a stack overflow) and its watchdog restarted it. The board isn't broken; a specific line in your code broke it, and the backtrace names the memory address where that happened.

Reading it in the right order

1. Fix the baud rate first

   Check the value inside your sketch's Serial.begin(115200) (or whatever number is there) and set Serial Monitor's dropdown to the exact same number. If the text becomes readable, stop here — you didn't have a crash.

2. Read the actual reset reason

   Look for a line starting with rst:0x — the chip telling you why it restarted, before you guess.

3. If you see a Guru Meditation Error, copy the whole block

   Including the line starting with Backtrace: — this is your firmware's own memory address trail, the specific point in your code where things went wrong.

4. If the pattern is clean repeating boot messages, suspect power first

   Try a separate 5V supply for the board, especially if a motor or sensor draws current right after boot — see the brownout guide linked above.

Letting Soldr do it

Paste your exact serial output — the real text, not a summary of it — into Soldr, along with the sketch you actually flashed. The diagnosis is grounded in that specific sketch, not a generic explanation of what a Guru Meditation Error usually means — it reads your code and your output together.

A worked example

Say you're running an ESP32-DevKitC reading a DHT22 every second, and it resets roughly every 8 seconds. Serial Monitor shows Guru Meditation Error: Core 0 panic'ed (LoadProhibited) right after the sensor-read line. That specific error means the code tried to read memory through a pointer that wasn't valid at that moment — commonly a sensor library call made before the previous reading cycle finished. Pasting that exact block plus the sketch grounds the explanation in your actual timing and library calls, not a generic "sometimes glitches" answer.

If it still doesn't make sense

• If the output is readable but doesn't match any of the three patterns above, or nothing prints at all — not even boot messages — the fault is more likely physical than logical: a USB cable that carries power but not data, or a wrong board selected in the IDE.
• A photograph of the actual wiring, checked with Soldr's vision diagnosis, is the next step from here rather than another serial capture.
• Still stuck? Paste the full serial log into Soldr and it will work through it with you.