ESP32 Keeps Rebooting After Uploading a Sketch

/ Troubleshooting

An ESP32 that keeps rebooting after uploading a sketch can be very confusing. The upload may finish successfully, but the board immediately restarts again and again. The serial monitor may show repeated boot messages, watchdog errors, brownout warnings, stack traces, or the same setup message printed over and over.

This problem is different from an upload failure. The new sketch is already on the ESP32. The problem is that the sketch, wiring, power supply or connected hardware causes the ESP32 to crash or reset after it starts running.

In many cases, the board is not damaged. The cause is usually a brownout, watchdog reset, bad pin choice, boot pin conflict, memory error, blocking code, invalid library use, or external hardware connected in a way that makes the ESP32 unstable.

Typical Symptoms

  • The sketch uploads successfully, but the ESP32 immediately restarts.
  • The serial monitor repeatedly prints the startup message from setup().
  • The serial monitor shows rst: boot messages again and again.
  • The ESP32 shows Brownout detector was triggered.
  • The ESP32 shows watchdog reset messages.
  • The board runs one sketch fine, but reboots with another sketch.
  • The board works alone, but reboots when modules are connected.
  • The ESP32 cannot be uploaded again unless BOOT is held manually.

First Important Point: Upload Success Means the USB Path Works

If the sketch uploaded successfully, the computer, USB cable, port and upload tool were probably good enough for programming. The reboot loop happens after the ESP32 starts running the sketch.

This means the next checks should focus on:

  • Power supply stability.
  • Serial monitor reset messages.
  • Code that crashes or blocks.
  • Libraries and memory use.
  • GPIO pins used by the project.
  • External hardware connected to the board.

Use the Serial Monitor First

Open the serial monitor at 115200 baud and press the reset button. Most ESP32 boards print useful boot information at startup.

You may see messages that indicate the reset reason, such as brownout, watchdog timeout, panic, stack overflow or illegal instruction.

If the output is unreadable garbage, check the baud rate first. ESP32 boot messages are commonly printed at 115200 baud.

Common Cause: Brownout Reset

A brownout means the ESP32 supply voltage dropped too low. The chip resets to avoid running unreliably.

This often happens when:

  • WiFi starts.
  • A relay switches.
  • A servo or motor moves.
  • An LED strip turns on.
  • A display backlight starts.
  • The board is powered through a weak USB cable.
  • Too many modules are powered from the ESP32 3.3V pin.

If the serial monitor shows Brownout detector was triggered, do not start by rewriting the sketch. Fix the power problem first.

Common Cause: Watchdog Reset

The ESP32 has watchdog timers that detect when important tasks are blocked for too long. If the sketch or a library blocks the CPU and does not allow system tasks to run, the watchdog may reset the chip.

Common causes include:

  • A very long or infinite loop without yielding.
  • Blocking code inside WiFi or web server tasks.
  • Disabling interrupts for too long.
  • Heavy calculations without delays or yields.
  • Waiting forever for a sensor, network connection or serial input.

For Arduino-style ESP32 sketches, adding small delays or restructuring blocking loops can help.

while (someCondition) {
  // Do not block forever without giving the system time.
  delay(1);
}

This is not a replacement for good program structure, but it can help identify watchdog-related problems.

Common Cause: Waiting Forever in setup()

Many examples contain code that waits forever for WiFi, Serial, a sensor or a display. If the condition is never met, the sketch may appear frozen or reset depending on what else is happening.

Examples of risky patterns:

while (WiFi.status() != WL_CONNECTED) {
  // Waiting forever
}

or:

while (!sensor.begin()) {
  // Waiting forever
}

A safer approach is to use a timeout:

unsigned long startTime = millis();

while (WiFi.status() != WL_CONNECTED) {
  delay(250);

  if (millis() - startTime > 10000) {
    Serial.println("WiFi timeout");
    break;
  }
}

This prevents the sketch from getting stuck forever when hardware or WiFi is not available.

Common Cause: External Hardware on Boot Strapping Pins

Some ESP32 pins are checked during reset to decide how the chip should boot. These are often called boot strapping pins.

If external hardware pulls one of these pins high or low at the wrong time, the ESP32 may fail to boot correctly or may enter the wrong mode.

This can happen with:

  • Relay modules.
  • Buttons.
  • LED circuits.
  • Sensors that drive a pin during boot.
  • Pull-up or pull-down resistors added to the wrong pin.

Depending on the ESP32 board and chip variant, pins such as GPIO0, GPIO2, GPIO12, GPIO15 and others may need special care. Always check the exact board pinout.

Common Cause: Using Flash or PSRAM Pins

Some ESP32 module pins are connected internally to flash memory or PSRAM. On many development boards, those pins should not be used for normal GPIO, even if they appear in some pinout diagrams.

If a sketch or external circuit interferes with flash or PSRAM pins, the ESP32 can crash, fail to boot or reboot repeatedly.

For classic ESP32-WROOM modules, GPIO6 to GPIO11 are commonly connected to the SPI flash and should not be used as normal I/O.

Common Cause: Bad GPIO Choice for Output Loads

A sketch may configure a pin as output and drive a connected load. If that load pulls too much current, backfeeds voltage, or affects a boot-sensitive pin, the ESP32 may reset.

Examples:

  • Relay input connected to a strapping pin.
  • LED connected without proper resistor.
  • MOSFET gate floating during boot.
  • Motor driver powered incorrectly.
  • 5V signal connected directly to a 3.3V ESP32 pin.

Disconnect external hardware and test the sketch with only the ESP32. If the reboot loop stops, the problem is likely in the connected circuit.

Common Cause: Stack Overflow or Memory Problems

ESP32 boards have much more memory than classic Arduino boards, but memory problems can still crash a sketch.

Common causes include:

  • Very large local arrays inside functions.
  • Recursive functions that never stop.
  • Large display buffers on boards with limited RAM.
  • Using many libraries together.
  • String fragmentation in long-running sketches.
  • Writing outside the bounds of an array.

If the serial monitor shows a panic, Guru Meditation error, stack canary error or backtrace, suspect a code crash rather than a simple upload issue.

Common Cause: Wrong Board Settings

ESP32 board settings in the Arduino IDE can matter. If the wrong board, flash size, PSRAM option or partition scheme is selected, the sketch may upload but not run correctly.

Check settings such as:

  • Board type.
  • Flash size.
  • PSRAM enabled/disabled.
  • Partition scheme.
  • Upload speed.
  • USB CDC settings on newer ESP32 boards.

This is especially important for ESP32-S3, ESP32-C3, ESP32-C6 and boards with PSRAM or native USB.

Common Cause: Library Not Compatible with the ESP32 Variant

Not every Arduino library works correctly on every ESP32 variant. Some libraries were written for AVR boards, some assume specific pins, and some use hardware features differently.

Problems are more likely with:

  • Old display libraries.
  • Timing-sensitive sensor libraries.
  • Libraries that disable interrupts.
  • Libraries written only for AVR Arduino boards.
  • Code that directly accesses AVR registers.

If the ESP32 reboots only when a specific library function is called, test that library with its simplest example sketch.

Common Cause: 5V Signals on ESP32 Pins

ESP32 GPIO pins are 3.3V logic pins. They are not generally 5V tolerant.

If a 5V module drives an ESP32 input pin directly, the ESP32 may behave unpredictably or be damaged.

Common risky connections include:

  • 5V sensor output to ESP32 GPIO.
  • 5V I2C pull-ups on SDA/SCL.
  • 5V UART TX line into ESP32 RX.
  • 5V encoder or interrupt output.

Use level shifting or choose 3.3V-compatible modules.

Common Cause: Crash Before USB Serial Starts

On newer ESP32 boards with native USB, a bad sketch may crash before USB serial is initialized. The board may seem to disappear from the computer, or the port may appear only briefly.

To recover:

  • Hold BOOT.
  • Press and release RESET or EN.
  • Keep BOOT held until upload starts.
  • Upload a simple known-good sketch.

Some boards have a specific bootloader or recovery procedure, so check the board documentation if the standard BOOT/RESET method does not work.

Simple Recovery Sketch

When recovering from a reboot loop, upload the simplest possible sketch.

void setup() {
  Serial.begin(115200);
  delay(1000);
  Serial.println("ESP32 recovery sketch running");
}

void loop() {
  delay(1000);
  Serial.println("Still alive");
}

If this sketch runs reliably, the ESP32 board is probably fine. The problem is in the previous sketch, connected hardware or power setup.

Step-by-Step Troubleshooting Method

  1. Open Serial Monitor at 115200 baud and read the reset message.
  2. Disconnect all external modules and loads.
  3. Upload a simple recovery sketch.
  4. If upload is difficult, hold BOOT during upload.
  5. Test the board alone with no WiFi and no external hardware.
  6. Add WiFi only and test again.
  7. Add one module at a time.
  8. Avoid boot strapping pins and flash pins.
  9. Check power supply and USB cable if resets happen under load.
  10. Test each library with its simplest example sketch before combining everything.

Quick Diagnostic Table

Symptom Likely Cause First Thing to Try
Brownout message Weak power supply or voltage dip Use better USB cable/supply and disconnect loads
Watchdog reset Code blocks too long Add timeout/yield/delay and remove infinite waits
Guru Meditation error Code crash, memory error or invalid operation Test smallest sketch and isolate library/function
Reboots only with external hardware connected Power, pin conflict or 5V signal problem Disconnect modules and reconnect one at a time
ESP32 does not boot after wiring relay Relay input affects boot strapping pin Move relay to safer GPIO
Port disappears on native USB board Sketch crashes before USB starts Force bootloader mode and upload recovery sketch

What Not to Do

  • Do not assume a reboot loop means the ESP32 is dead.
  • Do not disable the brownout detector instead of fixing power.
  • Do not keep all external modules connected while troubleshooting.
  • Do not use ESP32 boot strapping pins blindly.
  • Do not connect 5V signals directly to ESP32 GPIO pins.
  • Do not ignore reset messages in the serial monitor.

CANABLOX Practical Note

CANABLOX makes reboot-loop troubleshooting easier because the system can be separated into modules. Start with only the controller module and no external loads. Upload a simple recovery sketch and confirm that the controller runs reliably.

Then add CANABLOX modules one at a time. If the reboot loop starts after adding a specific module or external load, the problem is much easier to locate. This is one of the major advantages of a clean modular development system compared with a crowded breadboard full of jumper wires.

Conclusion

If an ESP32 keeps rebooting after uploading a sketch, the upload process itself probably worked. The problem begins when the sketch starts running.

Use the serial monitor to check the reset reason. Then isolate the problem by testing the ESP32 alone, checking power, avoiding unsafe GPIO pins, removing blocking code, and reconnecting external hardware one piece at a time.

Most reboot loops are caused by power dips, watchdog resets, pin conflicts or code crashes. Once the cause is isolated, the fix is usually much simpler than the symptom first suggests.

Shopping Cart
Scroll to Top