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

> Garbled text, a Guru Meditation crash block, or clean repeating reboots: three patterns, three causes, and how to read which one you have.

[HTML version](https://soldr.ai/docs/reading-serial-monitor-output)

[Docs](https://soldr.ai/docs) / When it doesn't work

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.

4 min read
Diagnosis
ESP32 · Arduino

## 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.

> **Clean repeating boot messages are usually a power problem, not a code problem** — A brownout from a supply that can't hold voltage under load — especially common when a motor, relay or solenoid switches on right after boot — resets the board without ever printing a crash block. If that's your pattern, our dedicated brownout guide covers the fix in full; this page focuses on reading what the serial output itself is telling you.

## Reading it in the right order

- **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.

- **Read the actual reset reason** Look for a line starting with `rst:0x` — the chip telling you why it restarted, before you guess.

- **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.

- **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.

> [screenshot] Soldr's serial diagnosis page: a pasted serial output block showing a Guru Meditation Error with a visible Backtrace line, the flashed sketch shown alongside it, and the diagnosis result panel below explaining the cause.

## 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.

> **Diagnosis is free** — Pasting serial output and asking what's wrong never costs credits. You only spend credits when Soldr generates something for you.

## 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.

| Part | Why it's there | Price |
|---|---|---|
| ESP32-DevKitC (Black) | the controller in this example | ₹340 |
| DHT22 | the sensor whose read call crashed | ₹100 |
| Core of the example | the fix is in the code, not the parts | ₹440 |

## 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.

[Previous ESP32 reboots on motor start](https://soldr.ai/docs/esp32-reboots-when-motor-starts)
[Next Photograph your breadboard](https://soldr.ai/docs/photograph-your-breadboard)