Power management

Power consumption is a key design parameter for many STM32-based systems, especially for battery-powered and energy-harvesting applications. This chapter describes STM32 power management concepts and explains how they apply to projects developed with STM32CubeIDE for Visual Studio Code.

STM32 power domains and clocks overview

Most STM32 microcontrollers share core concepts that significantly affect power consumption:

  • Power domains

    Depending on the device family, there can be separate domains for the core, backup, analog, or communication peripherals. Some domains can remain powered while others are switched off.

  • Clock sources

    • High-speed clocks: high-speed internal oscillator (HSI), high-speed external oscillator (HSE), phase-locked loop (PLL), and system clock (SYSCLK)

    • Low-speed clocks: low-speed internal oscillator (LSI) and low-speed external oscillator (LSE), typically used for the real-time clock (RTC) and low-power timers

    • Derived bus clocks: AHB, APB, and peripheral clocks

  • Voltage scaling and regulators

    Some STM32 families offer:

    • Multiple performance or voltage ranges

    • On-chip SMPS or LDO regulators with different modes

    • Independent backup domain supply for RTC and backup registers

The following factors mainly determine power consumption:

  • The system clock frequency and active clock sources

  • Which peripherals and domains are enabled

  • How often the core is active compared to time spent in a low-power mode

  • Whether analog blocks, such as ADCs and comparators, remain enabled

STM32 low-power modes

While the exact naming and capabilities vary by family, the most common low-power modes are:

  • SLEEP mode

    • The CPU clock is stopped

    • Most peripherals and clocks can remain active

    • Wakeup from any enabled interrupt

    • Lowest entry and exit latency with modest power reduction

  • STOP modes

    • Main regulators and PLLs are usually turned off; variant names include STOP0, STOP1, and STOP2, depending on the device family

    • SRAM and register contents can be retained

    • Use low-speed oscillators (LSI or LSE) and a limited set of wakeup sources, such as RTC, external interrupts, and some communication peripherals in low-power mode

    • Significant power savings with medium wakeup latency

  • STANDBY or SHUTDOWN mode

    • Almost all logic is powered down

    • Only the backup domain, RTC (if configured), and some wakeup pins remain powered

    • Lowest power and highest wakeup latency

    • On most families, exiting this mode resembles a reset, so the application must reinitialize the system

For each mode, the reference manual and datasheet provide:

  • Exact current consumption figures

  • Available wakeup sources

  • Which memories and registers are retained

When designing your application, select the deepest mode that still satisfies:

  • Wakeup latency requirements

  • Required peripherals during low-power operation

  • Data retention needs

Configuring power features in STM32Cube configuration tools

When you use STM32Cube configuration tools integrated into STM32CubeIDE for Visual Studio Code, such as STM32CubeMX-based .ioc configuration, you typically configure power-related options in the following sections:

  • Clock configuration

    • Set system and peripheral clocks to the minimum frequencies that meet performance requirements

    • Use LSE or LSI for the RTC and low-power timers when possible

    • Avoid enabling unused oscillators

  • Power configuration

    Depending on the device family, this section can include:

    • Voltage scaling range

    • Regulator type and mode (LDO, SMPS, low-power regulator)

    • Brownout reset (BOR) configuration

    • Battery-backed domain (VBAT) options

  • Peripherals

    • Choose low-power capable peripherals when available, for example, use the low-power timer (LPTIM) instead of a general-purpose timer (TIM) for certain tasks

    • Configure wakeup sources explicitly, such as external interrupt (EXTI) lines, RTC alarms, and wakeup pins

The configuration tool then generates:

  • Initialization code that configures clocks, regulators, and voltage scaling

  • Hardware abstraction layer (HAL) and low-layer (LL) functions you can call to enter the various low-power modes

  • RTC and EXTI configuration to support wakeup scenarios

Note

After significant clock or power changes, regenerate the code and test the low-power entry and exit sequence again, especially when using STOP or STANDBY modes.

Firmware patterns for low-power operation

STM32 projects usually implement power management through simple, repeatable patterns.

Event-driven main loop

A typical low-power main loop structure: 

while (1)
{
  /* Handle pending events/flags */
  Process_Application_Events();

  /* Prepare system for low-power */
  Prepare_For_LowPower();

  /* Enter low-power mode until next interrupt */
  HAL_SuspendTick();        /* Optional: stop SysTick if not needed */
  HAL_PWR_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_SLEEPENTRY_WFI);
  HAL_ResumeTick();         /* Resume SysTick after wakeup */

   /* Reconfigure clocks if a STOP mode was used */
  SystemClock_Config_AfterStop();
}

Key ideas:

  • Interrupts and event flags drive application work instead of tight polling loops.

  • The core spends most of its time in WFI/WFE-based low-power modes between events.

Entering low-power modes

HAL and LL drivers provide functions such as:

  • HAL_PWR_EnterSLEEPMode()

  • HAL_PWR_EnterSTOPMode() or family-specific STOP variants.

  • HAL_PWR_EnterSTANDBYMode()

Before entering deeper low-power modes, typically:

  • Stop or reconfigure non-essential peripherals.

  • Ensure all DMA transfers are completed or placed in low-power compatible mode.

  • Handle external devices, for example, put sensors or radios into their own low-power modes.

After wakeup: restoring clocks and peripherals

When the device exits STOP or STANDBY mode, reinitialize clocks and any peripherals affected by the clock change:

  • For STOP modes that turn off PLL or HSE:

    • Re-enable oscillators and PLL.

    • Re-select system clock source.

    • Re-initialize any peripherals whose clocks depend on those sources.

  • For STANDBY or SHUTDOWN:

    • Treat wakeup like a reset: rerun SystemInit() and SystemClock_Config().

    • Use backup registers or RTC to detect that wakeup originated from low-power mode and restore application state if needed.

RTC and low-power timers

The RTC and low-power timers are central to STM32 low-power designs.

Using RTC as a wakeup source

The RTC can wake the device from STOP and STANDBY modes using:

  • Alarm (A or B)

  • Wakeup timer

  • Timestamp or tamper events (family-dependent)

Typical pattern:

  1. Configure LSE (or LSI) and RTC in the Cube configuration (.ioc).

  2. Enable the desired wakeup source, for example, wakeup timer.

  3. Before entering low-power:

    • Program RTC alarm or wakeup counter for the next event.

    • Clear related flags.

  4. Enter STOP or STANDBY mode.

  5. In the RTC interrupt handler, set an application flag indicating wakeup reason.

Low-power timers (LPTIM)

On devices featuring LPTIM , you can:

  • Generate periodic interrupts from low-frequency clocks while the core is in STOP mode.

  • Use LPTIM as a low-power time base for scheduler-like functionality.

When possible, prefer LPTIM over general-purpose timers for tasks that must run while the system is in low-power mode.

Debugging and measuring low-power behavior

Debugging low-power modes can be challenging because stopping the core and clocks affects the debug interface.

Debug configuration considerations

Many STM32 families offer options such as Debug in STOP or Debug in STANDBY modes (configured in DBGMCU registers).

Consider the following:

  • Keeping debug enabled in STOP or STANDBY mode increases power consumption

  • For accurate current consumption measurements, disable these debug options and run the firmware without an active debugger

  • During development:

    • Start with SLEEP mode, which is debug-friendly

    • Move to STOP or STANDBY mode once the application logic is stable

Measuring current consumption

To validate power behavior:

  • Use a dedicated power measurement tool or a precision ammeter in series with the board supply

  • Measure the following:

    • Active current at different system clock frequencies

    • Current in SLEEP, STOP, and STANDBY modes

    • Transitions between modes, including peaks during wakeup

  • Compare results with the MCU datasheet and application notes to determine whether the configuration meets expectations

Tip

Many STM32 Nucleo and evaluation boards expose jumpers that allow measuring MCU current independently from other circuitry, such as LEDs, debug probes, and external components. Ensure non-MCU loads do not distort your measurements.

Typical STM32 low-power use cases

Periodic sensor node

  • Most of the time, the MCU operates in STOP or STANDBY mode

  • RTC wakeup occurs every few seconds or minutes

  • On wakeup:

    • Re-enable sensors and ADC

    • Acquire data

    • Optionally send data via radio or wired interface

    • Return to low-power mode

Key STM32 features used:

  • RTC with LSE

  • STOP or STANDBY mode

  • GPIO and ADC low-power configuration

Always-on timekeeping with backup domain

  • RTC clocked by LSE, powered from VBAT

  • Main system supply can be completely removed

  • After power restoration:

    • Application reads time from RTC

    • No need to resynchronize from an external source

Key STM32 features used:

  • Backup domain and VBAT pin

  • Backup registers to store application state, such as configuration settings and last known time synchronization information

Communication-oriented designs

For designs with radios or high-speed interfaces:

  • Use low-power modes between bursts of activity

  • Coordinate MCU and external transceiver power states

  • Consider using STOP mode with retention when waiting for network events such as Bluetooth Low Energy (BLE) advertising or periodic beacons

STM32 features commonly used:

  • LPTIM or RTC for scheduling

  • External interrupt wakeup from radio or transceiver

  • Selective clock gating to communication peripherals

Common pitfalls and troubleshooting

MCU does not wake from low-power mode

Possible causes:

  • Wakeup source not correctly configured or enabled

  • Corresponding interrupt not enabled in the nested vectored interrupt controller (NVIC)

  • Flags not cleared before entering low-power mode

  • The selected low-power mode does not support the wakeup source

What to check:

  • Verify EXTI, RTC, and LPTIM configuration in the generated code

  • Check interrupt priorities and NVIC enables

  • Review the reference manual section on wakeup sources for the selected low-power mode

Excessive current consumption in low-power mode

Possible causes:

  • Unnecessary clocks or peripherals left enabled

  • GPIO pins left floating or in analog mode when not appropriate for the hardware design

  • Debug options keeping clocks or domains active

  • External components, such as sensors, level shifters, and pull-ups, dominating the current draw

What to check:

  • Ensure only required clocks are enabled before entering low-power

  • Configure unused GPIOs to a defined state such as analog input or pull-up/down as recommended in the datasheet

  • Disable Debug in STOP or Debug in STANDBY while measuring current

  • Measure the power consumption of the board without the MCU, if possible

Application misbehaves after wakeup

Symptoms:

  • Peripherals stop working

  • Communication interfaces become unstable

  • Time base or delays are no longer accurate

Typical causes:

  • Not reconfiguring clocks or PLL after STOP mode

  • Not reinitializing peripherals that are clock-dependent

  • Unclear software distinction between cold boot and wakeup from low-power mode

What to check:

  • Ensure the wakeup path calls the correct clock reconfiguration function

  • For STANDBY or SHUTDOWN exits, treat them like a reset and reinitialize everything

  • Use backup registers or RTC flags to determine whether the system resumed from low-power mode and restore the application state appropriately