How do low-power modes work on STM32? How do you wake from Stop mode?

STM32 MCUs provide a hierarchy of low-power modes with increasing power savings and increasing recovery complexity. Sleep mode stops only the CPU core — all peripherals, clocks, and SRAM contents remain active. Current drops from tens of mA to a few mA. Any interrupt wakes the CPU, and execution resumes immediately from where it stopped. Stop mode goes further: it disables the HSI, HSE, and PLL (the entire high-speed clock tree is shut down), but preserves SRAM and register contents. Current drops to the microamp range (typically 2-30 uA depending on the STM32 family and voltage regulator mode). All peripheral clocks stop, so peripherals freeze in their current state. Standby mode is the deepest: it disables the voltage regulator entirely, losing all SRAM and register contents (only backup domain registers and RTC survive). Current drops to sub-microamp levels (0.3-2 uA). Wake-up from Standby is effectively a system reset.

Waking from Stop mode requires a wake-up source that can operate without the main clock tree: EXTI interrupts (external pin edges routed through the EXTI controller, which runs on a separate asynchronous detection circuit), the RTC alarm or wakeup timer (clocked by the 32.768 kHz LSE or LSI, which remain active in Stop mode), or on some families, LPUART (Low-Power UART, clocked by LSE). The wake-up event triggers the CPU to restart, but critically, the clock configuration reverts to HSI at 16 MHz — the HSE and PLL are off and must be reconfigured. If your application immediately accesses peripherals whose baud rates or timing were calculated for 168 MHz, they will be wrong by a factor of 10x until you reconfigure the PLL.

The wake-up sequence is therefore: (1) wake event triggers exit from Stop; (2) CPU resumes executing on HSI at 16 MHz; (3) firmware re-enables HSE and waits for HSERDY; (4) reconfigures and enables the PLL, waits for PLLRDY; (5) switches SYSCLK back to PLL. Only then should the application resume normal peripheral operations. A well-designed low-power application encapsulates the clock restoration in a SystemClock_Config() function called immediately in the wake-up path. The total wake-up latency is dominated by the HSE startup time (2-10 ms) and PLL lock time (sub-millisecond), making Stop mode unsuitable for applications that need sub-millisecond wake-to-active response times — use Sleep mode instead for those cases.