WHY BLACKOUTS ARE EASIER
Off is a surprisingly well-behaved state.
If a system loses power abruptly and completely, every powered component eventually stops. The failure may still be inconvenient, but diagnosis begins from a clean proposition: energy disappeared.
A brownout is messier. Supply voltage remains present while falling below the range where one or more components are guaranteed to operate correctly. Some devices may reset. Others may continue running. Oscillators may shift or stop. Flash or EEPROM writes may become unsafe. Communications transceivers may drive lines while their peers are resetting. Analog references may wander before digital logic gives up. A regulator may enter dropout while a downstream supervisor still believes the system is alive.
The result can look less like “power failed” and more like a software bug, damaged peripheral, random bus fault, corrupted configuration, impossible sensor value, or device that only recovers after somebody physically removes the battery.
OPERATING RANGE
A datasheet operating voltage is a contract, not a suggestion.
Digital logic is often described as though every state is either zero or one and every supply is either on or off. Real devices specify an operating range. Inside that range, timing, logic thresholds, memory access, oscillator behavior, peripheral performance, and current consumption are characterized to defined limits. Outside it, those promises weaken or disappear.
A microcontroller may execute instructions below its recommended minimum voltage. That does not mean it is executing them correctly. The CPU core, flash array, SRAM, clock tree, ADC, GPIO, serial peripherals, and external components can each have different undervoltage sensitivities.
This creates one of the ugliest diagnostic categories in embedded work: plausible continued operation outside the guaranteed envelope. The board appears alive. LEDs blink. A serial port sometimes answers. The processor may even run for seconds. None of those observations establish that the machine remains trustworthy.
BROWNOUT RESET
The point of brownout reset is to fail earlier and more cleanly.
Many microcontrollers include brownout reset, sometimes called BOR, BOD, low-voltage detect, voltage monitor, or a similar vendor-specific name. The mechanism watches the supply and holds or forces the device into reset when voltage falls through a configured threshold.
The philosophy is simple: if the processor cannot be trusted below a certain supply voltage, stop executing before reaching that region.
A useful brownout implementation has more than a threshold. It also needs response time and hysteresis. Response time determines how quickly the reset logic reacts to a sag. Hysteresis helps prevent rapid reset-release-reset chatter when the supply hovers around the threshold. Many devices also provide a power-up delay or oscillator-start delay so reset is not released the instant voltage first crosses the line.
These details matter because a slow, noisy power ramp can cross the threshold many times. A supervisor that releases reset too eagerly may create a boot loop that looks like intermittent firmware failure.
THRESHOLD SELECTION
The correct reset threshold protects the whole timing path.
Choosing a brownout level is not just matching a round number printed in a configuration register.
The processor's maximum safe clock frequency may depend on supply voltage. External flash may require a higher minimum voltage than the CPU core. A radio, sensor, FPGA, level shifter, or motor-control gate driver may stop behaving correctly before the processor does. If the MCU happily keeps running while the storage device is outside specification, the system may still corrupt data before reset arrives.
The correct threshold therefore depends on the weakest critical element in the active system and on what the firmware is allowed to do near the boundary. In some products the MCU brownout detector is sufficient. In others an external supervisor monitors the primary rail or several rails and controls reset, write protection, power enable, or a safe-state line.
POWER SEQUENCING
One rail can die while another keeps talking.
Modern systems often have multiple rails: battery or input supply, 12 V, 5 V, 3.3 V, 1.8 V, analog rails, core rails, memory rails, isolated domains, and switched peripheral supplies. Their rise and fall times are not identical.
During power loss, stored energy in bulk capacitors and downstream loads can keep one domain alive longer than another. A microcontroller may retain enough voltage to drive GPIO into a peripheral whose supply has already collapsed. That current can flow through protection structures and partially power the supposedly dead device through signal pins. A communication bus can become biased through one participant. A sensor may send nonsense while its reference is falling. A motor driver may drop logic power while the high-energy power stage is still energized.
That is why power-down sequencing deserves the same attention as power-up sequencing. “Everything eventually reaches zero” is not a sequence specification.
ENERGY STORAGE
Capacitors turn power loss into a race.
Bulk capacitance is useful. It also means power does not disappear instantly.
A first-order estimate of stored capacitor energy is:
E = 1/2 C V²
That energy supports the load while voltage falls. If the current draw is roughly known, engineers can estimate how much useful time remains between detecting power loss and crossing the minimum safe voltage.
That interval may be used to stop writes, save a small piece of transactional state, park an actuator, close a file, record a reset reason, or disable high-current loads. But the budget needs margin. A shutdown routine that requires 40 ms when the worst-case hold-up is 42 ms is not resilience. It is optimism with a stopwatch.
NONVOLATILE MEMORY
Power failure turns storage writes into transactions whether you designed them that way or not.
Configuration updates, flash erase/program operations, filesystems, databases, and log writes are vulnerable to interrupted power. The exact behavior depends on the memory technology and controller, but the architectural lesson is stable: a state update should not assume it will complete.
Common defensive techniques include double-buffered configuration records, version numbers, checksums, append-only journals, atomic rename patterns, copy-on-write structures, commit markers written last, and recovery logic that can identify the newest complete record after reboot.
The important distinction is between data integrity and power detection. A perfect brownout detector does not make a badly designed persistent-state update atomic. Likewise, robust transactional storage does not make it safe to execute arbitrary code below the processor's voltage specification. These defenses solve different layers of the problem.
LOAD TRANSIENTS
The grid can be fine while the board browns itself out.
Brownouts are not only utility events. The board can create its own undervoltage event when a load changes faster than the supply path can respond.
Radios transmit. Motors start. heaters switch. LEDs pulse. processors leave sleep. FPGAs change activity. USB devices enumerate. A cable with too much resistance drops more voltage under load. A battery with rising internal resistance sags. A regulator reaches current limit. A switch or connector adds contact resistance. A long trace or harness contributes inductance.
If the input falls only when a load step occurs, the root cause may be source impedance, wiring, regulator response, local decoupling, connector quality, battery state, or a load profile that changed after a firmware update.
This is why a multimeter reading of “5.0 V” at idle proves very little about transient power integrity.
MEASUREMENT
Measure voltage where the victim sees it.
Power debugging is full of measurements taken at convenient places instead of relevant places.
If the processor resets, probe the supply and ground at the processor or immediately adjacent decoupling network. If a peripheral fails, observe its local rail and reference. Use enough oscilloscope bandwidth and a short ground connection so the probing method does not invent ringing or miss narrow events. Trigger on reset, supervisor output, power-good, or the suspected load transition.
Also capture time relationships. A supply trace without the reset signal tells only half the story. A useful capture may include input rail, regulated rail, reset, power-good, and one representative load-control signal.
Questions worth answering include: How low did the rail fall? For how long? What was the slope? Did reset assert before or after the rail crossed the guaranteed operating range? Did reset release cleanly? Did another rail remain active and back-power the device?
RESET REASON
Make the reboot leave evidence.
Many microcontrollers expose reset-cause flags: power-on reset, brownout reset, watchdog, external reset, software reset, lockup, or other device-specific causes. Read and preserve them early in boot before initialization code clears them.
That small habit can turn a field report from “device randomly rebooted” into “brownout detector asserted 47 times after radio transmit.” It also helps distinguish a power integrity problem from watchdog recovery, manual reset, firmware update, or deliberate supervisory action.
Reset-cause logging should itself be designed for interrupted power. A counter that is rewritten unsafely on every boot can become a new corruption mechanism. Use wear-aware, transactional recording appropriate to the storage technology.
RECOVERY
A reset is only useful if startup is idempotent.
Brownout reset gets the processor out of undefined operation. It does not guarantee the surrounding system returns to a coherent state.
After restart, firmware should assume that the previous execution may have stopped anywhere. Outputs may have been partially changed. External devices may not have reset at the same time. A transaction may have been incomplete. A motor may still be moving. A remote peer may believe a command is in progress.
Good startup logic establishes known outputs, validates persistent state, reinitializes or interrogates peripherals, detects incompatible peer state, clears stale transactions, and returns the system to a defined safe operating mode before resuming normal work.
The more stateful the machine, the less credible “just reboot it” becomes as a complete recovery strategy.
TESTING
Do not test power failure with only a switch.
A switch mostly tests one trajectory: reasonably fast loss and reasonably ordinary restoration. Real power faults have shape.
A useful test plan sweeps supply voltage downward at different rates, upward at different rates, and repeatedly through the reset threshold. Add short sags that recover without reaching zero. Add load transients. Vary temperature and battery condition when relevant. Test interrupted writes. Test power loss during firmware update. Test one rail disappearing before another. Test rapid off-on cycles that do not allow all capacitors to discharge.
Observe whether the system resets deterministically, whether outputs remain safe, whether stored state survives, whether peripherals restart coherently, and whether the failure is recorded.
The goal is not to prove the product can survive one theatrical unplugging. The goal is to characterize the boundary between trustworthy operation and deliberate shutdown.
BOTTOM LINE
Fail before the hardware becomes imaginative.
A robust embedded system treats undervoltage as a defined operating condition with explicit detection, safe thresholds, sequencing assumptions, storage behavior, reset evidence, and restart rules.
Blackout says the machine stopped. Brownout asks which parts were still alive while the promises disappeared.
If a device exhibits rare corrupted settings, impossible bus faults, boot loops, half-powered peripherals, or failures that vanish after a long unplug, put power integrity near the top of the suspect list.
SOURCE TRAIL
Technical starting points.
Microchip — Reset, Watchdog, Power-up Timer, and Brown-Out Reset specifications
Analog Devices — Basic Switching-Regulator Layout Techniques