A low-power mode is a reduced-activity operating state in which a microcontroller or SoC disables or slows some combination of its CPU, peripherals, clocks, and memory in order to decrease current consumption. Most MCUs offer several graduated modes, trading off wakeup latency and available peripherals against how deeply power consumption is reduced.
In practice
Low-power modes are named and structured differently across vendors. MSP430 parts define LPM0 through LPM4 (and LPM4.5), each progressively shutting down more of the clock system, with LPM4.5 achieving sub-microamp leakage on many devices, though exact current figures and the extent of RAM and register state loss vary by specific part. STM32 families offer Sleep, Stop, and Standby (plus Shutdown on newer lines), with Stop modes typically suspending the CPU and high-speed oscillators while keeping SRAM live and certain wakeup sources armed. PIC and AVR parts use similar naming conventions -- sleep, idle, power-down -- with device-specific peripheral retention rules. Always consult the specific datasheet; current figures and retained state vary significantly even within a single vendor's product line.
Entering a low-power mode correctly requires more than calling a sleep instruction. The CPU and peripheral clocks should generally be configured before entry, pending DMA transactions and UART flushes should complete, and all necessary wakeup sources (RTC, GPIO EXTI, LPUART, comparator, etc.) must be armed beforehand. A common pitfall is entering a deep sleep before an ongoing peripheral transaction finishes, which either corrupts the transfer or prevents the device from reaching the target mode. The blog post "Racing to Sleep" covers this timing problem in detail -- briefly, the goal is to finish all work as quickly as possible and reach the lowest appropriate mode before the next event, minimizing time spent in active run mode.
Wakeup time is a critical parameter that is often overlooked. Coming out of deep stop or standby modes on many MCUs requires re-initializing clocks, PLLs, and sometimes peripherals, which can take hundreds of microseconds. For latency-sensitive applications, a shallower sleep mode that retains clock state may consume more average power than a deep mode if the wakeup overhead forces the CPU to run longer after each event. Profiling average current across the full sleep/wake/process/sleep cycle -- not just the sleep current in isolation -- is the correct way to evaluate a power strategy.
For battery-powered IoT devices, low-power modes are typically the dominant factor in runtime. As discussed in "7 Essential Steps for Reducing Power Consumption in Embedded Devices," choosing the right mode hierarchy, minimizing active-time work, and keeping wakeup sources lean can extend battery life by orders of magnitude compared to a naive always-on design. Network activity, as explored in "SIGFOX - A new network technology for IoT comms?", is often the largest active-mode energy draw, making aggressive sleep between transmissions essential.
Discussed on EmbeddedRelated
Frequently asked
What is the difference between sleep, stop, and standby modes on an STM32?
On STM32 devices,
Sleep mode halts the CPU core but generally leaves
AHB/
APB peripherals and
SRAM clocked, giving the shortest wakeup
latency (a few cycles), though exactly which clocks remain active depends on the device and configuration. Stop mode gates the high-speed oscillators and optionally the
voltage regulator, retaining SRAM and peripheral register state but requiring clock re-initialization on wakeup, which typically takes tens to hundreds of microseconds. Standby mode cuts the main voltage regulator entirely, retaining only the backup domain; SRAM content is lost, so wakeup is effectively a reset. Exact current figures, retained peripherals, and wakeup sources differ between STM32 sub-families, so always check the reference manual for your specific part.
Why does my device draw more current than the datasheet sleep figure suggests?
Datasheets specify sleep current under controlled lab conditions, typically with all I/O pins in a defined state, no floating inputs, and specific voltage and temperature conditions. In practice, floating
GPIO pins that oscillate near a logic threshold, enabled internal pull resistors, active peripherals left running, and leakage through attached external components can all add significant current on top of the bare
MCU figure. Measuring with all I/O in a known state and reviewing each peripheral's enable bit before entry is the standard debugging approach.
What does 'Racing to Sleep' mean in the context of low-power design?
Racing to sleep refers to the strategy of running the CPU as fast as possible to complete a task and then immediately entering a low-power mode, rather than running at a lower clock speed for a longer time. Because dynamic power scales with both frequency and voltage but the total energy for a fixed amount of work is roughly constant, finishing quickly and sleeping longer often yields better average power than stretching the work over time at a lower clock. The blog post 'Racing to Sleep' goes into the tradeoffs and the conditions under which this holds.
Can peripherals like UART, SPI, or ADC keep running during a low-power mode?
It depends on the specific
MCU and the depth of the
sleep mode. On many STM32 Stop modes, for example, a low-power
UART (LPUART) clocked from the LSE or LSI can continue to receive data and trigger wakeup, while standard USARTs clocked from the HSI or
PLL will be inactive. Similarly, some devices allow an
RTC, comparator, or low-power
ADC to operate during stop. Deeper modes like Standby typically disable nearly all peripherals. Always verify which clocks and peripherals are gated in each mode in the reference manual.
How does an RTOS affect low-power mode entry?
An RTOS tick
interrupt, if left running at its normal rate (commonly 1 kHz for
FreeRTOS), will wake the CPU periodically even when no tasks are ready, defeating deep sleep strategies. Most RTOSes support a tickless idle mode -- FreeRTOS calls this configUSE_TICKLESS_IDLE -- where the
scheduler programs a timer for the next scheduled wakeup and then enters a hardware sleep, suppressing unnecessary tick interrupts. The blog post 'OS influence on power consumption' covers how RTOS configuration choices affect real-world idle current.
Differentiators vs similar concepts
Low-power mode is sometimes conflated with clock gating or dynamic voltage and frequency scaling (DVFS). Clock gating selectively disables clocks to idle peripherals while the CPU remains fully active; it is often one mechanism used internally when entering a low-power mode, but it is not a low-power mode itself. DVFS reduces operating frequency and supply voltage to lower dynamic power during active execution, keeping the CPU running rather than halting it. True low-power modes reduce or halt CPU activity (and typically gate most clocks), achieving the largest power reductions at the cost of responsiveness, though some vendor-defined modes in this category still retain selected clocks or partial CPU state depending on the implementation.
