How Do You Configure STM32 Low-Power Modes (Sleep, Stop, Standby)?

Detailed Explanation

STM32 devices implement a hierarchy of low-power modes, each trading faster wake-up and more retained state for higher current draw. Choosing the right mode — and correctly configuring its wake-up path — is one of the highest-leverage decisions in any battery-powered STM32 design, since the difference between Stop and Standby mode alone is typically an order of magnitude or more in average current draw for a sensor that spends most of its life idle.

Before working with low-power modes, understanding the STM32 clock tree is essential — every low-power mode is defined by which clocks it gates, and Stop mode's clock behaviour on wake is a common source of bugs.

The Three Core Low-Power Modes

Sleep mode — the CPU clock (HCLK) is gated; the core stops executing instructions, but every peripheral, RAM bank, and clock domain outside the core keeps running exactly as configured. Any enabled interrupt — a timer tick, a UART byte arrival, a GPIO EXTI edge — wakes the core in a handful of clock cycles, and execution resumes at the instruction immediately after the WFI (Wait For Interrupt) or WFE (Wait For Event) that entered Sleep mode. Current draw in Sleep mode is only modestly lower than Run mode, because peripherals and the system clock tree remain active — the saving comes purely from stopping CPU instruction fetch and execution.

Sleep mode suits any application where the CPU is idle between short bursts of work but the wake-up latency budget is too tight for anything deeper — for example, a control loop waiting on a timer tick every few hundred microseconds.

Stop mode — every clock in the 1.8V domain is stopped, including the CPU, all peripheral clocks, and (depending on family and configuration) the PLL and HSE. SRAM and all register contents are retained; the voltage regulator can be configured in either normal or low-power mode during Stop, trading a small amount of extra current for a faster wake-up. Stop mode can only be exited by an EXTI line — this includes any GPIO pin configured as an external interrupt source, plus a set of internal EXTI lines that typically include the RTC alarm and RTC wake-up timer.

The critical detail engineers miss: Stop mode always resumes on HSI, the internal RC oscillator, regardless of the clock source that was active before entry. If the application was running from the PLL or HSE before Stop mode, the clock tree must be explicitly reconfigured in the wake-up handler — code that assumes SystemCoreClock still reflects the pre-Stop configuration will run peripherals at the wrong baud rate, sample ADCs at the wrong rate, or miscalculate any delay derived from the system clock.

Standby mode — the deepest mode with retained real-time state. The 1.8V core domain is powered down entirely; only the backup domain survives — the RTC, a small number of backup registers, and on some families (STM32L4, U5) an additional backup SRAM block that can be configured to retain a limited amount of application state. Waking from Standby is electrically indistinguishable from a power-on reset: execution restarts at the reset vector and the full startup sequence (including SystemInit() and CubeMX-generated peripheral re-initialisation) runs again — there is no resuming from where the code left off. Wake-up sources are limited to the dedicated WKUPx pins, an RTC alarm or wake-up timer event, or an IWDG reset.

Some families (L4, G4, U5, H7) add intermediate modes — Stop 0/1/2 with progressively lower current and higher wake latency, and Shutdown mode below Standby with even lower retention and current — refer to the specific family's Reference Manual PWR chapter for the exact mode ladder and current figures, since these vary meaningfully across series.

Typical Current Draw and Wake Latency

Exact current figures depend heavily on the specific part, silicon revision, temperature, and which peripherals (LSE, RTC, backup SRAM) remain active during the low-power state — always verify against the datasheet's electrical characteristics table for the exact part number rather than relying on family-level generalisations. As a general ordering (not absolute values):

The ultra-low-power families — STM32L4, L5, U5 — are purpose-built to minimise Stop and Standby current and are the natural choice when battery life dominates the design; see Which STM32 Family Should You Use? for the full family comparison including power profile.

Entering Low-Power Modes with HAL

// Sleep mode — CPU clock gated, wakes on any interrupt
HAL_PWR_EnterSLEEPMode(PWR_MAINREGULATOR_ON, PWR_SLEEPENTRY_WFI);

// Stop mode — all 1.8V domain clocks gated, wakes only on EXTI
HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);

// Immediately after waking from Stop, the clock is running on HSI —
// reconfigure the clock tree before resuming normal operation
SystemClock_Config();

// Standby mode — core domain powered down; this call does not return.
// Execution restarts at the reset vector on wake.
HAL_PWR_EnterSTANDBYMode();

HAL_PWR_EnterSTOPMode() and HAL_PWR_EnterSLEEPMode() return once the wake-up event occurs; HAL_PWR_EnterSTANDBYMode() never returns — the next code the device executes is the reset vector. CubeMX's Power Consumption Calculator (in newer STM32CubeMX versions) estimates average current draw for a given duty cycle across modes, useful for early battery-life budgeting before hardware exists.

Configuring Wake-Up Sources

EXTI (for Stop mode): Configure the GPIO pin as an external interrupt in CubeMX (GPIO mode: External Interrupt, rising/falling/both edge), enable the corresponding EXTIx_IRQn in NVIC, and implement HAL_GPIO_EXTI_Callback(). The interrupt handler runs after the clock is restored, so any GPIO or peripheral access inside it must assume the post-Stop (HSI) clock configuration until SystemClock_Config() has run.

RTC alarm or wake-up timer (for Stop and Standby): The RTC runs from LSE (external 32.768 kHz crystal) or LSI (internal RC) and continues operating through Stop and Standby — it is part of the backup domain. Configure HAL_RTC_SetAlarm_IT() for a wake at a specific date/time, or HAL_RTCEx_SetWakeUpTimer_IT() for a periodic wake-up at a configurable interval (useful for a sensor that samples every N seconds regardless of wall-clock time). LSE is strongly preferred over LSI for any application requiring accurate wake timing — LSI's frequency tolerance is typically several percent, which compounds into significant timing drift over a multi-hour or multi-day sleep interval.

WKUP pins (for Standby): A small, fixed set of GPIO pins can wake the device from Standby via HAL_PWR_EnableWakeUpPin(). On families with configurable polarity, both rising- and falling-edge wake-up are supported; on older families the WKUP pins are fixed to a specific polarity — check the family's Reference Manual.

The RTC Backup Domain

The backup domain is a separate power domain, supplied by VBAT when the main supply is absent, that survives Standby mode (and, with a coin-cell or supercapacitor on VBAT, survives complete removal of the main supply). It contains the RTC, its LSE oscillator, and a small number of 32-bit backup registers (RTC->BKPxR) — on families with a backup SRAM block (L4, U5, H7), a larger retained memory region is also available, requiring __HAL_RCC_BKPSRAM_CLK_ENABLE() and a backup-domain write-protection unlock.

A common pattern: before entering Standby, write a small state marker into a backup register; on wake (which restarts at the reset vector), read PWR->SR1 (or PWR_SR, depending on family) for the Standby/wake-up flag, and if set, read the backup register to determine what to resume rather than re-running full cold-start initialisation.

Design Considerations

• Match the mode to the actual wake-up latency budget, not the lowest current figure available. Standby draws the least current but incurs a full reset and re-initialisation on every wake — for an application waking frequently (every few seconds) to take a quick reading, the re-initialisation overhead itself can dominate average power. Stop mode's SRAM/register retention often produces better real-world average current for frequent-wake applications despite its higher instantaneous current during the sleep interval.
• Use the RTC wake-up timer with LSE, not a busy-wait or SysTick-based delay, for periodic wake intervals. SysTick requires the core clock running, defeating Stop/Standby entirely. LSE gives an accurate, low-power timing reference that continues through every low-power mode.
• Budget for peripheral re-initialisation time after Stop mode wake. ADCs, PLLs, and some analog peripherals (op-amps, comparators, the internal voltage reference) require a settling time after clocks resume — a design that samples an ADC in the first instructions after Stop-mode wake without an appropriate settling delay reads inaccurate or garbage values.
• Account for GPIO state during low-power modes. GPIO output states are retained through Sleep and Stop, but the peripheral driving them (if any) is not clocked — a PWM output frozen mid-cycle in Stop mode can leave an external driver stage in an unintended state. Explicitly force safe GPIO states before entering a low-power mode if the application drives external hardware.
• Measure actual current draw on the target board, not the datasheet figure alone. Datasheet current figures are measured under specific, often idealised conditions (all peripherals disabled, LSE/LSI configuration specified). Board-level leakage through pull-up/pull-down resistors, external sensor quiescent current, and LED indicators frequently dominate the MCU's own low-power-mode current — measure the complete board with a current probe or a source-measure unit before committing to a battery capacity.

For product designs where battery life is a hard requirement, Zeus Design's firmware development team profiles and optimises STM32 low-power firmware against a target battery life and duty cycle.

Common Mistakes

• Assuming Stop mode preserves the pre-sleep clock configuration. Stop mode always exits on HSI. Firmware that doesn't call SystemClock_Config() (or an equivalent manual PLL/HSE re-enable) immediately after waking runs every subsequent peripheral at the wrong clock rate — UART baud rates, SPI clock speeds, and any timer-derived delay are all silently wrong until the clock tree is restored.
• Expecting Standby mode to resume execution where it left off. Standby is a full reset. Any application that needs to remember state across a Standby cycle must explicitly save it to a backup register or backup SRAM before entering Standby, and explicitly check the wake-up flag and restore that state after the reset-vector restart — global variables in normal SRAM are not preserved.
• Forgetting that an interrupt not routed to an EXTI line cannot wake the device from Stop mode. A peripheral interrupt handler that works fine in Sleep mode silently never fires in Stop mode if the peripheral's interrupt is not one of the EXTI lines (or is a peripheral, like most timers, whose clock is gated in Stop). This produces a device that appears to hang permanently in Stop mode with no obvious cause.
• Letting the IWDG expire during an intentionally long Stop or Standby period. The IWDG runs from LSI independent of the core clock and keeps counting through Stop and Standby. A long low-power interval that exceeds the configured IWDG timeout resets the device mid-sleep, which looks like a spontaneous unexplained reset — see why does my STM32 keep resetting unexpectedly? for the general reset-cause diagnosis, including checking RCC_CSR/RCC_RSR for an IWDG reset flag.
• Leaving unused peripherals and GPIOs in a high-current configuration before entering a low-power mode. Floating GPIO inputs, active pull-ups on unused lines, and peripherals left clocked but idle all add unnecessary current in Sleep and Stop modes. Configure unused GPIOs to analog mode (the lowest-current state) and explicitly disable peripheral clocks that aren't needed during the low-power interval.
• Not testing low-power current with a debugger attached. SWD debug connections keep certain clock domains active to maintain the debug session, which can mask the true current draw of Stop or Standby mode. Measure final low-power current with the debugger fully disconnected and running from a standalone power source.

For the interrupt priority model that governs which wake-up interrupts can preempt others once the device is running again, see How Do You Configure STM32 NVIC Interrupt Priorities?. For battery capacity and runtime calculations that make use of the current figures from this page, see how to calculate battery life. For the equivalent implementation on other MCU platforms, see nRF52 power optimisation and ESP32 deep sleep and power management.