Why Your ESP32 Brownouts Only Happen When WiFi Connects

The serial monitor sits there quietly doing nothing wrong, and then the instant the ESP32 finishes associating with the access point, it reboots. Brownout detector was triggered, says the log, followed by the bootloader banner again. Nothing else in the code is doing anything unusual at that moment. Nothing else needs to be.

WiFi association is the one thing an ESP32 routinely asks its power rail to do that it otherwise never has to: supply a short, sharp burst of current with essentially no warning. Most supplies can't quite manage it, and the brownout detector is just the messenger that tells you.

What the brownout detector is actually watching

The ESP32 has a hardware brownout detector (BOD) watching the internal 3.3V rail, VDD33. If that rail dips below a configured threshold, roughly 2.43V by default, the BOD resets the chip immediately. That is a deliberate safety feature: running logic on a sagging supply produces corrupted flash writes and garbled RF far more often than it produces a graceful failure.

The trigger isn't the average voltage across your whole session. It's a dip lasting a few hundred microseconds, which is exactly the kind of thing an average multimeter reading will never show you, and exactly the kind of thing your power supply is worst at responding to.

Why association specifically is the expensive bit

Idle WiFi, or a chip that's simply reading a sensor over I2C, draws very little current. Associating with an access point is a different story: it's a short, dense cluster of radio transmissions, not one transmission.

Probe request and response
Authentication frames
Association request and response
The DHCP exchange that usually follows straight after

Every one of those is a burst from the power amplifier keying up at close to maximum transmit power, because the chip has no idea yet how strong the link is and defaults to being loud. Espressif's own hardware design guidance for the ESP32 calls for a supply capable of at least 500 mA with headroom for spikes above that, specifically because of these bursts.

A supply that averages fine under constant load can still sag hard for the duration of one such burst. That's long enough, electrically, to pull VDD33 under the BOD threshold and short enough that you'll never see it on a cheap meter.

Why the supply can't keep up

Nothing about a typical prototyping setup is built for a fast, high-current transient. A few likely culprits, usually stacked on top of each other:

A thin or long USB cable, which adds resistance exactly where you can't afford it
A USB port or hub that current-limits or simply can't source the peak
Long, thin jumper wires from a bench supply into a breadboard
Breadboard contact resistance, which is worse than it looks and gets worse with age
No bulk capacitance near the chip to absorb the spike locally

That last point is the one people miss most often. A linear regulator reacts to load changes in microseconds at best, and a spike measured in hundreds of microseconds can be over before the regulator has finished noticing it happened. Local capacitance, not regulator response time, is what actually catches the spike.

Actually seeing the spike

An average-reading multimeter is the wrong tool here. It samples slowly and reports a mean, so a 200-microsecond dip to 2V vanishes into a reading that still says "3.3V, looks fine".

You need something with real time resolution. An oscilloscope probe on VDD33, triggered on the falling edge, is the direct way to see it. A cheap USB logic analyser with an analogue channel, or a fast current sensor breakout like an INA219 logged at a high sample rate, will also catch it if a scope isn't to hand.

If you have neither, a rough trick still helps: add a large electrolytic capacitor (1000uF or more) right at the 3V3 pin as a test, and see whether the resets stop. If they do, you've confirmed a supply transient without ever seeing the waveform.

Fixing it, versus hiding it

It's tempting to just turn the detector off, via menuconfig's brownout options or by writing to the RTC_CNTL_BROWN_OUT_REG register directly. Don't. That doesn't fix the sag, it just removes the chip's ability to protect itself from it. The reboots may stop, but you'll trade them for silent flash corruption or a chip that locks up under RF interference instead of resetting cleanly.

What actually works is giving the spike somewhere to come from other than the wall:

A bulk electrolytic capacitor (100 to 470uF) plus a small ceramic one, placed as close to the chip's 3V3 pin as your layout allows
A regulator genuinely rated for the ESP32's peak draw, such as an AMS1117 or ME6211 variant sized with margin, not just its steady-state average
Short, thick power wiring, and a breadboard swapped for direct soldering once you're past the prototyping stage
A decent USB cable and a port or hub that isn't already current-limited by something else on the bus

Most boards that brown out on association stop doing it entirely once there's a few hundred microfarads sitting right next to the chip. It's a two-minute fix for a problem that looks, from the serial monitor, like it should be a software bug.