In this guide
ESP32 Brownouts Explained: Fixing Random Resets and Boot Loops
Your ESP32 runs fine for minutes, then reboots out of nowhere — usually the moment Wi-Fi connects, a relay clicks, or a motor starts. The serial monitor shows "Brownout detector was triggered" and the board restarts. This is almost never a code bug: the chip's supply voltage sagged below its minimum, the on-chip brownout detector pulled the reset line, and your program started over. This guide explains what a brownout actually is, why the ESP32 is especially prone to them, the three usual culprits, and the fixes in the order you should try them — with real numbers and a bench workflow you can run in one sitting.
The problem: resets that track your hardware, not your code
A brownout is a dip in the supply voltage that is deep enough to threaten the chip but too short to look like a power cut. The ESP32's brownout detector watches the internal rail and resets the chip when it falls to around 2.4–2.5 V (the default threshold is near 2.43 V; it can be adjusted in the ESP-IDF configuration). The signature is unmistakable: the serial monitor prints a brownout message right before the reboot, and the crash correlates with something electrical — Wi-Fi turning on, a relay firing, a servo moving — rather than with a particular line of code.
If your resets happen at perfectly regular intervals with no hardware event nearby, suspect a software watchdog or a memory bug instead. Brownouts follow the loads.
Why the ESP32 sags its own supply
The ESP32's Wi-Fi radio draws current in short, sharp bursts. Transmit bursts can pull several hundred milliamps for fractions of a millisecond — roughly ten times what the chip sips while idling. Any power path has resistance: the USB cable, the board's traces, the voltage regulator, the contacts. When a burst flows through that resistance, Ohm's law does the rest — a voltage drop appears, the rail dips, and if the dip crosses the brownout threshold the chip resets.
Three parts of a typical student setup make this worse than it needs to be:
- Thin USB cables. Cheap or long charging cables have high resistance. A 0.5-ohm cable carrying a 400 mA burst drops 0.2 V before the board even sees the power — and the board's own regulator needs its own headroom on top of that.
- Weak 5 V → 3.3 V regulation. Many dev boards use a small linear regulator (often an AMS1117-class part) that must burn off (5 V − 3.3 V) as heat. Under burst loads the regulator's output can wobble, and a hot regulator can thermally throttle, making the dip deeper.
- No bulk capacitance near the chip. The board's small ceramic capacitors handle high-frequency noise, but they cannot supply a 400 mA burst for hundreds of microseconds. Without a larger reservoir capacitor, the rail has nothing to draw on during the burst except the regulator and cable.
The three usual culprits, in order of likelihood
Culprit 1: the cable and power source. Powering the board from a laptop USB port through a thin cable is the most common cause. Laptop ports often deliver marginal voltage to begin with, and the cable eats the rest. Switch to a known-good short cable on a proper 5 V / 2 A wall adapter and a surprising number of "mysterious resets" vanish.
Culprit 2: shared supply with heavy loads. Relays, servos and motors on the same 5 V rail inject their own inrush current. A relay coil pulling in or a motor starting can drag the rail down exactly when the ESP32 is also doing Wi-Fi — the two dips add up and cross the threshold together.
Culprit 3: marginal regulator or missing bulk capacitor. Some clone boards skimp on the output capacitor, or the regulator is already running hot from powering peripherals. The fix here is electrical, not software.
Diagnosing it properly
Match your symptom to the cause before changing anything:
| Symptom | Likely cause |
|---|---|
| Resets only when Wi-Fi connects or transmits | Burst current exceeding what the cable/regulator can deliver |
| Resets when a relay/motor/servo activates | Shared-supply inrush; needs supply separation or a reservoir capacitor |
| Resets immediately and repeatedly at boot | Supply far too weak, or the regulator overheating into shutdown |
| "Brownout detector was triggered" in the serial log | Confirmed brownout — the detector fired, this is not a watchdog or crash |
| Resets with no brownout message, no hardware correlation | Software fault: watchdog timeout, stack overflow, or an exception — debug the code |
A multimeter on the 3.3 V pin will rarely catch the dip — it is over in microseconds, far faster than the meter's display updates. What you can do with a meter is check the steady-state 5 V at the board's input while the system runs: if it reads 4.6 V instead of 5 V, your cable is already losing 0.4 V before any burst arrives. An oscilloscope on the 3.3 V rail during a Wi-Fi connect will show the dip directly if you have access to one.
The fixes, in the order to try them
1. Fix the power source first
Use a short, thick USB cable and a wall adapter rated 5 V / 2 A or better. This single change resolves the majority of student brownout cases because it attacks the highest-resistance part of the path. Keep the cable under a metre.
2. Add a bulk capacitor across the supply
Solder or breadboard a 470 µF to 1000 µF electrolytic capacitor directly across the board's 5 V and GND pins (mind the polarity — electrolytics are polarised), as close to the board as possible. Keep the board's existing 100 nF ceramic capacitors in place; they handle high-frequency noise while the big capacitor supplies the burst energy. A rule of thumb: 470 µF is the practical minimum for Wi-Fi bursts; 1000 µF if you also drive relays from the same rail. This is the classic, cheapest hardware fix and it works because the capacitor feeds the burst locally instead of asking the cable to.
3. Separate the heavy loads
Give motors, relays and servos their own supply (or at least their own regulator output) with a common ground. The ESP32's rail should never share a wire with a motor. If you must share a source, power the ESP32 through its own regulator fed from the raw input, and put a Schottky diode plus a reservoir capacitor on the ESP32 side so inrush on the shared rail cannot drag the chip's rail down.
4. Reduce the burst load in software
If hardware changes are not possible, soften the demand: lower the Wi-Fi TX power (WiFi.setTxPower()), avoid connecting and transmitting at the same instant as switching loads, and prefer light-sleep between transmissions over staying awake at full radio duty. These are mitigations, not cures — treat them as backup.
5. The brownout detector setting (last resort)
You can lower or disable the brownout threshold in the ESP-IDF sdkconfig / Arduino board options. Do this only after fixing the supply, never instead of it: a chip running below its specified voltage can corrupt flash writes and behave unpredictably in ways that look like new, weirder bugs. Disabling the detector hides the symptom and lets the real problem damage your data.
A bench workflow you can finish in one sitting
- Reproduce the reset and read the serial log — confirm the brownout message is present.
- Swap to a short cable and a 2 A adapter; re-test. Fixed? Stop here.
- Measure steady-state 5 V at the board input while running. Below ~4.8 V means the path is still lossy — try a different cable or power the board's 5 V pin directly.
- Add the 470–1000 µF capacitor at the board; re-test with Wi-Fi connecting and loads switching.
- Still resetting? Split the supplies: separate regulator or supply for motors/relays, common ground.
- Only then consider software mitigations or the detector setting.
Frequently asked questions
Will a bigger capacitor damage anything?
No — 470–1000 µF across the 5 V input is safe. The only caveat is inrush when you first plug in: the empty capacitor briefly looks like a short circuit. Cheap USB ports can trip on it; a proper adapter handles it. Do not go to tens of thousands of microfarads without understanding inrush limiting.
Can I power the ESP32 from a LiPo battery?
Yes, but mind the regulator: a single LiPo cell swings from 4.2 V down to about 3.0 V as it discharges, and most board regulators need roughly 1 V of headroom above 3.3 V output. Below about 4.3 V input the regulator drops out and brownouts return. Use a board with a low-dropout regulator designed for battery use, or a small boost/buck module.
Does deep sleep help with brownouts?
It reduces average current dramatically, but the wake-up Wi-Fi burst is just as sharp. A sleeping device with a weak supply will brownout the instant it wakes and transmits — sleep is a battery-life tool, not a power-integrity fix.
My board resets even with nothing connected. Is it dead?
Not necessarily — a bare board resetting at Wi-Fi connect with a good cable usually means the onboard regulator is failing or counterfeit, or the USB source is weak. Try a different board and a different cable before pronouncing it dead.
Limitations
This guide covers the classic supply-side brownout on ESP32 dev boards — cable, regulator, capacitance and load sharing. It does not replace measuring your actual rail with an oscilloscope for production designs, and the numbers here (burst currents, capacitor sizes, thresholds) are typical values for common dev boards, not guarantees for every clone. If your design runs on batteries, solar, or harvested energy, the power architecture needs its own analysis beyond adding a capacitor. And remember: the brownout detector is a safety net, not an annoyance — if it keeps firing after these fixes, something in your power path still needs attention, not a higher tolerance for dips.