How to tell if I bricked my microcontroller board?

Good news: most “bricked” boards are only confused, not dead.

Here’s how to systematically tell what you’re dealing with.

1. What “bricked” really means

In hobby/embedded talk people say “bricked” when:

• The board doesn’t run your code anymore
• And normal upload methods stop working

But actually bricked means:

Even with the right programmer, boot pins and power,
you still can’t erase or reprogram the chip → the silicon itself is done.

The goal is to figure out which side you’re on.

2. Step 1 – Check basic power (is it even alive?)

With the board unplugged, visually inspect:

• Any burn marks, cracked ICs, melted plastic?
• Any component looking discolored or bubbled?
• Smell of burnt electronics?

Then plug it in and check:

1. Power LED

If your board has a power LED and it doesn’t light with a known-good cable/supply → power path issue (maybe not the MCU itself).

2. Voltage rails (multimeter)

• Measure 5 V and 3.3 V pins (if exposed).
• No 3.3 V = regulator or short problem.
• Extremely low voltage (e.g. 0.5–1 V on 3.3 V rail) usually means a short or a fried chip dragging the rail down.

3. Chip gets very hot?

If the MCU is too hot to touch within a few seconds just from powering it → likely damaged silicon.

If power rails look normal and nothing cooks your fingers, there’s hope.

3. Step 2 – Signs of life (even weak ones)
A. LEDs / onboard behavior

• Does any user LED blink or turn on briefly after reset?

Many boards have a “heartbeat” or blink sketch by default.

• If previously you had a blink program and it’s now totally dead, that’s a clue—but still not proof of a hard brick.

B. USB boards (Arduino, STM32, ESP32 dev boards, etc.)

Connect via USB and check:

• On Windows: Device Manager → “Ports (COM & LPT)” or “USB devices”
• On Linux: dmesg right after you plug it in
• On macOS: ioreg -p IOUSB or check /dev/cu.*

Questions:

• Does anything new appear when you plug the board?

If yes → USB interface is alive.

• Does it appear with a different name than usual?

Sometimes bootloader vs application presents different IDs.

No USB enumeration at all + you’re sure the cable and port are OK → more serious, but still not always fatal (e.g. USB stack crashed, wrong clock config, etc.).

4. Step 3 – Try the bootloader / recovery mode

Most MCUs/dev boards have a ROM bootloader that is very hard to kill.

Examples

Arduino (ATmega328, etc.)

Try double-pressing RESET just before uploading, or use “Upload using programmer”.

STM32

• Use BOOT0 pin:

Set BOOT0 high, reset the board → it should start the ROM bootloader (UART/USB/DFU, depending on chip).

• Try tools like STM32CubeProgrammer to see if the chip responds in DFU/serial mode.

ESP32 / ESP8266

• Hold BOOT/IO0 while pressing EN/RESET → enters serial bootloader.
• Use esptool.py or the Arduino IDE to see if it can detect the chip.

RP2040 (Raspberry Pi Pico)

Hold BOOTSEL while plugging USB → shows up as a mass storage drive.

If the chip still responds in bootloader mode, you have not bricked it.
Just erase & re-flash with a known-good “blink” or minimal test program.

5. Step 4 – Try a hardware programmer/debugger

If normal USB/serial upload fails:

Use the low-level debug interface:

• SWD/JTAG for STM32, ARM boards
• ISP for AVR
• Vendor-specific programmer for others

Questions:

• Does the programmer see the device ID?
• Can you erase and flash the chip (even a blank program)?

If the programmer can:

• Read the chip ID
• Mass-erase flash
• Reprogram

→ The board is NOT truly bricked. The problem is in:

• Bootloader
• Clock configuration
• Option bytes/fuses
• Or the code itself (e.g. you disabled USB or reconfigured pins)

If the programmer cannot detect the chip at all, and you’re 100% sure about wiring, power and correct settings → that’s a big red flag.

6. Step 5 – Hardware health test (unpowered)

With the board unpowered:

1. Measure resistance between 3.3 V and GND:

• A stable reading of a few kΩ or more is normal.
• A reading of just a few ohms or near 0 Ω → likely a short (could be a fried MCU or a shorted capacitor).

1. Visually check:

• Solder bridges around fine-pitch pins
• Any reversed polarized component (electrolytic caps, diodes, etc.)

If you remove the MCU (on a custom board) and the short disappears → the chip is probably dead.

7. When is it really bricked?

You can reasonably call it “bricked” when:

1. Power rails are correct and stable, and
2. The chip does not show up in any way (no USB/serial/LED activity), and
3. A proper hardware programmer cannot:

• Read the device ID
• Erase or program flash

1. You’ve ruled out wiring errors, shorts, and wrong programmer settings.

At that point, it’s likely electrically damaged (overvoltage, ESD, 5 V on 3.3 V pins, wrong polarity, etc.) and replacing the chip/board is the realistic option.

8. Quick decision tree (mental checklist)

1. Power LED on? 3.3 V present? Chip not boiling hot?
   Yes → go on

2. Any USB/serial/LED sign of life?
   Yes → probably just firmware/bootloader issue

3. Can you enter ROM bootloader (BOOT0/BOOTSEL/etc.)?
   Yes → erase & re-flash → NOT bricked

4. Can a hardware programmer see the chip ID and erase it?
   Yes → NOT bricked, just low-level config or code issue

5. None of the above work even though wiring & power are correct
   → Likely actually bricked / physically damaged.