MCU low-power modes

In short: MCU low-power modes trade off how much of the chip you keep alive — sleep halts the CPU but keeps clocks, stop freezes clocks while retaining RAM, and standby powers down almost everything except a wake source — letting a battery device drop from milliamps to nanoamps between the events it actually needs to handle.

If you are building anything that runs off a coin cell, a lithium-polymer pack, or a harvested-energy supply, the single most important design decision is not the clock speed or the peripheral set — it is how aggressively, and how correctly, you exploit the microcontroller's low-power modes. A sensor node that is "always on" at 10 mA will flatten a 230 mAh CR2032 in about a day. The same node that sleeps at 1 µA and wakes for 5 ms every second can last years on the identical cell. This article explains the standard sleep/stop/standby hierarchy, the wake sources that pull you back out, and how to build an honest current budget.

The three-tier model: sleep, stop, standby

Almost every modern MCU family — ST's STM32, NXP's Kinetis and LPC, Microchip's SAM/PIC, TI's MSP430 and the ARM Cortex-M cores underneath many of them — exposes a low-power hierarchy that boils down to three conceptual tiers, even when the marketing names differ (TI calls them LPM0–LPM4.5; ST calls them Sleep, Stop, and Standby/Shutdown).

• Sleep gates the CPU clock but leaves the bus clocks, SRAM, and most peripherals running. The core stops executing instructions; a DMA transfer or a UART byte still proceeds. Wake latency is essentially zero — a few clock cycles — because nothing was powered down. Typical draw on a Cortex-M4 at 48 MHz: a few milliamps, down from ~10 mA active.
• Stop freezes all high-speed clocks (the PLL and the main oscillator are off) but keeps SRAM and register contents powered, so your program state survives. Only a low-frequency oscillator (a 32.768 kHz crystal or an internal low-power RC) and asynchronous peripherals keep ticking. Current collapses to the single-digit microamp range. Wake takes a few microseconds while the main oscillator restarts.
• Standby / shutdown cuts power to the core domain entirely. SRAM is lost (except, on many parts, a small retention region or a handful of backup registers). You wake into a full reset and re-run startup code. This is where you reach hundreds of nanoamps or less — an STM32L4 in Standby with RTC is around 0.6 µA, and in Shutdown around 30 nA.

Rule of thumb: every rung you descend the ladder cuts current by roughly one order of magnitude — ~10 mA active, ~1 mA sleep, ~5 µA stop, ~0.5 µA standby — while wake latency climbs from cycles to microseconds to a full reset of tens of milliseconds.

Wake sources: how you get back out

A low-power mode is only useful if something can pull the MCU out of it deterministically. The deeper the mode, the fewer peripherals remain alive to do so. The usual wake sources are:

• RTC / low-power timer — a 32.768 kHz-driven alarm that fires on a schedule. This is the workhorse for duty-cycled sensors: sleep for 1 s, wake, sample, transmit, sleep again. It survives even standby because it lives in the always-on backup domain.
• GPIO / external interrupt — a button press, a motion-sensor pin, an accelerometer's "activity" interrupt. On many parts only specific wake-up pins (EXTI or WKUP lines) work from standby; ordinary EXTI works only from sleep/stop.
• Watchdog — an independent watchdog can wake or reset a hung device. Pair this with your low-power design so a stuck peripheral doesn't silently drain the battery; see our note on the watchdog timer and how to service it safely.
• Peripheral match events — some MCUs keep a low-power UART, I²C address match, or analog comparator running in stop mode, waking the core only when a real frame or threshold crossing arrives.

Building an honest current budget

Average current, not peak current, sets battery life. The arithmetic is a weighted mean across every state the device visits in one period:

I_avg = Σ (I_state × t_state) / T_period

Take a soil-moisture node that wakes once per minute, spends 8 ms active at 8 mA sampling an ADC, 120 ms at 15 mA transmitting over BLE, and the remaining ~59.87 s in standby at 1.5 µA:

That is 1,954 µA·s per 60 s, so I_avg ≈ 32.6 µA. A 230 mAh CR2032 (derated to ~200 mAh usable) gives roughly 200 mAh / 0.0326 mA ≈ 6,100 hours ≈ 8.5 months — and the table makes it obvious where the budget goes: the radio dominates, not the sleep floor. Shaving the transmit window, not the standby current, is where the next gain lives.

Measure, don't trust the datasheet. Datasheet standby figures assume every pin is configured, pull-ups disabled, and unused regulators off. A single floating input or a left-enabled debug interface can add tens of microamps — dwarfing the mode you worked so hard to reach.

Common pitfalls that wreck the budget

• Floating GPIOs. An undriven CMOS input sits near the switching threshold and leaks. Set unused pins to a defined level or analog-input before sleeping.
• Peripherals left clocked. Forgetting to disable a running ADC, DAC, or the SWD/JTAG debug block keeps a domain alive. Many parts need you to explicitly disable the debug module in low-power modes.
• Brown-out detector and voltage reference. These quiescent loads are easy to overlook and can be the dominant term once the CPU is asleep.
• Clock restart cost. Waking from stop to run a crystal PLL can take hundreds of microseconds of active-current settling — frequent shallow wakes can cost more than one deep sleep.

Verifying it on silicon and in simulation

Before tape-out or even board bring-up, power intent is captured formally. For SoC-class designs the UPF (Unified Power Format, IEEE 1801) describes power domains, retention registers, and isolation cells; tools such as Synopsys Design Compiler / PrimePower, Cadence Genus and Joules, and Siemens Questa Power Aware simulate whether a "standby" domain actually isolates and retains correctly. On a commercial MCU you verify empirically with a source-measure unit or a current-probe analyser (Keysight, Nordic's Power Profiler Kit) logging the microamp-to-milliamp dynamic range the budget above assumes. If your team is designing the silicon rather than buying it, low-power implementation is core to a physical-design flow — the kind of work covered in Avecas's VLSI design services.

For the firmware side, the discipline is the same one you apply to interrupt latency and deterministic interrupt handling: know exactly which state the core is in, what remains clocked, and what will bring it back. Our full embedded systems course catalogue walks through these flows on real STM32 and MSP430 hardware.

Ready to design devices that last years on a coin cell? Join the CourseTron Embedded Low-Power & RTOS track and build a duty-cycled sensor node end to end, from UPF intent to measured microamps.

Frequently asked questions

What is the difference between stop mode and standby mode?

Stop mode freezes all clocks but keeps SRAM and CPU registers powered, so your program resumes exactly where it left off after a few microseconds. Standby cuts power to the core domain entirely: SRAM is lost (apart from a small retention area or backup registers) and the MCU wakes through a full reset, re-running startup code. Standby draws far less current but costs you state and a longer wake.

Why is my measured sleep current much higher than the datasheet value?

Datasheet figures are best-case: every pin configured, pull resistors off, debug interface disabled, unused regulators and the brown-out detector off. In practice floating inputs, a left-enabled SWD/JTAG block, or a running peripheral clock typically add tens of microamps. Audit every pin and peripheral before trusting the budget, and measure with a current analyser.

Does a lower-power mode always save energy?

Not always. Deeper modes have higher wake and clock-restart costs. If you wake very frequently, the settling current of restarting a PLL or crystal can exceed what you saved by going deeper. Compute average current across a full period for each candidate strategy rather than assuming the deepest mode wins.

Which wake source should I use for a periodic sensor?

An RTC alarm or low-power timer in the always-on backup domain is ideal for scheduled sampling, because it survives standby and is driven by a low-current 32.768 kHz oscillator. Use a wake-up GPIO pin for event-driven designs like a button or motion sensor, and pair either with an independent watchdog to recover from hangs.