ESP32 Brownout Detector Was Triggered: Complete Fix Guide (2026)

ESP32 Brownout Detector Was Triggered: Complete Fix Guide (2026)

If you've just flashed new firmware to your ESP32 and your Serial Monitor is spamming a wall of text that ends in "Brownout detector was triggered" followed by a reboot loop, you're not alone. This is one of the most common — and most misunderstood — ESP32 errors, and in almost every case it has nothing to do with your code. It's a power delivery problem, and it's fixable in under ten minutes once you know what to check.

In this guide, we'll break down exactly what the brownout detector is, why it's triggering on your board, and walk through six real fixes ranked from "try this first" to "last resort," including the correct way to disable it in software if you ever need to.

What Does "Brownout Detector Was Triggered" Actually Mean?

The ESP32 has a built-in hardware circuit called the Brownout Detector (BOD). Its job is to constantly watch the chip's core voltage rail. If that voltage dips below a safe threshold — typically around 2.43V on most ESP32 variants — the BOD assumes the chip is about to behave unpredictably (corrupt flash writes, glitch the CPU, or crash randomly) and forces an immediate reset as a protective measure.

In other words, this isn't a bug. It's the chip successfully doing its job and telling you: "my voltage just dropped, so I'm restarting myself before something worse happens." The real question isn't how to silence the message — it's why your voltage is dropping in the first place.

Common Causes of Brownout Resets

1. Underpowered USB Port or Cable

This is the single most common cause. Many USB ports — especially on laptops, unpowered hubs, and older USB 2.0 ports — cannot reliably supply the current spikes the ESP32 draws during WiFi or Bluetooth radio bursts (which can briefly spike to 400–500mA). A thin or long USB cable adds resistance and makes this worse, even if the port itself is rated correctly.

2. WiFi/Bluetooth Radio Current Spikes

The moment your code calls WiFi.begin() or initializes Bluetooth, the RF amplifier draws a sharp current spike. If your power source can supply steady current but can't respond fast enough to that spike, the voltage sags for a few milliseconds — long enough to trip the BOD.

3. Missing or Undersized Decoupling Capacitor

On bare ESP32 modules (not dev boards) or custom PCBs, a missing bulk capacitor on the 3.3V rail near the chip is a frequent culprit. Dev boards like the DevKitC usually have this built in, but breadboard prototypes and hand-soldered projects often don't.

4. Battery or LiPo Voltage Sag

If you're running from a LiPo battery or a set of AA batteries, voltage naturally sags under load, especially as the battery discharges. A battery that reads "fine" at rest (3.7V) can sag well below the ESP32's minimum during a WiFi burst.

5. Long or Thin Power Wires on Breadboards

Breadboard power rails and jumper wires have real resistance. Combined with a current spike, even a few centimeters of thin wire can cause enough voltage drop to trigger a brownout.

6. Faulty or Counterfeit USB Cable / Power Bank

Charge-only cables (no proper data/power gauge wires) and cheap power banks with aggressive current limiting are a surprisingly common cause, especially with ESP32-CAM and ESP32-S3 boards that draw more current than the base ESP32.

How to Fix "Brownout Detector Was Triggered" (Step-by-Step)

Fix 1: Swap the USB Cable First

Before touching any code, replace your USB cable with a short, thick, known-good data cable — ideally one rated for at least 2A. This alone resolves the majority of brownout resets.

Fix 2: Use a Powered USB Port or Wall Adapter

Plug directly into a wall USB power adapter (5V/1A minimum, 2A preferred) instead of a laptop port or unpowered hub. If you must use a laptop, use a rear/motherboard USB port rather than a front-panel or hub port.

Fix 3: Add a Bulk Capacitor on the 3.3V Rail

If you're working with a bare module or custom board, add a 100–470µF electrolytic (or tantalum) capacitor between 3.3V and GND, as close to the ESP32's power pins as possible. This smooths out the fast current spikes that trip the BOD.

Fix 4: Power From a Dedicated Regulator, Not a Battery Directly

If you're running on batteries, feed them through a quality 3.3V LDO or buck regulator rated for at least 1A output, rather than connecting the battery straight to the ESP32's 3V3 pin. This decouples your chip from raw battery sag.

Fix 5: Shorten and Thicken Your Power Wiring

On breadboards, replace long thin jumper wires on the power rails with shorter, thicker ones, and consider running a direct wire from your power source straight to the ESP32's VIN/5V pin instead of relying on the breadboard's rail.

Fix 6: Lower the Brownout Threshold in Software (Use With Caution)

Only after confirming your power supply is genuinely solid should you consider adjusting the BOD sensitivity. This does not fix the underlying voltage problem — it only makes the chip tolerate a lower voltage before resetting, which can mask instability rather than solve it. Use this for debugging or in Arduino IDE where the more precise ESP-IDF Kconfig option isn't available:

#include "soc/soc.h"
#include "soc/rtc_cntl_reg.h"

void setup() {
  // Disables the brownout detector - diagnostic use only,
  // NOT a substitute for fixing your power supply
  WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0);

  Serial.begin(115200);
  Serial.println("Brownout detector disabled - power supply must be fixed separately");
}

void loop() {

}

In ESP-IDF projects, the proper way is to adjust the threshold via idf.py menuconfig under Component config → ESP32-specific → Brownout Detector, where you can lower the trigger voltage instead of disabling protection entirely.

How to Confirm the Fix Worked

After applying a fix, run a WiFi or Bluetooth-heavy sketch (like a simple WiFi.begin() connection test) for at least 10–15 minutes continuously. If the board stays connected without random resets and the Serial Monitor shows no further brownout messages, your power delivery issue is genuinely resolved — not just masked.

Related ESP32 Guides

If you're troubleshooting power and stability issues, these guides on this site cover closely related territory:

• ESP32 Watchdog Timer (TWDT) Tutorial: Fix Reset Errors in Arduino Core 3.x
• ESP32 Sleep Modes Explained: Deep Sleep, Light Sleep & Hibernation Power Guide
• ESP32 WiFi Example: How to Connect ESP32 to WiFi Using Arduino IDE

Frequently Asked Questions

Is "brownout detector was triggered" dangerous for my ESP32?

No — it's a protective mechanism, not damage. The chip is resetting itself to avoid unpredictable behavior from low voltage. Repeated brownouts won't harm the ESP32, but they indicate a power delivery problem worth fixing.

Can bad code cause a brownout reset?

Indirectly, yes. Code that triggers heavy current draw (WiFi/Bluetooth init, driving multiple high-current peripherals, or rapid GPIO switching) at the same moment can expose a marginal power supply that was otherwise "just barely" working.

Should I just disable the brownout detector permanently?

It's not recommended. Disabling it removes a safety net that protects your flash memory from corruption during voltage sags. Fix the power supply instead — use it only as a temporary diagnostic step.

Why does this only happen when WiFi connects?

WiFi and Bluetooth radios draw sharp, brief current spikes when transmitting. A power source that handles steady-state current fine can still fail to respond fast enough to these spikes, causing a momentary voltage dip that triggers the BOD.