A sleep mode is a low-power state in which a microcontroller or processor halts some or all of its clocks and disables selected peripherals to reduce current consumption while retaining enough state to resume normal operation. Most MCUs offer several sleep depths, each trading off power savings against wake latency and the subset of peripherals that remain active.
In practice
Sleep modes appear in nearly every battery-powered or energy-harvesting design. On typical ARM Cortex-M devices, the architecture defines two baseline states -- Wait For Interrupt (WFI) and Wait For Event (WFE) -- which halt the CPU core while leaving memory and selected peripherals powered. Vendor silicon then layers additional modes on top: for example, STM32 parts offer Sleep, Stop, and Standby modes with progressively lower current (from milliamps down to single-digit microamps), while MSP430 parts define LPM0 through LPM4/LPM4.5 with similar progression. PIC and AVR families have their own named equivalents.
A common design pattern is "racing to sleep": the firmware wakes on an event, does the minimum work necessary, and returns to the deepest feasible sleep state as quickly as possible. The energy cost of a wake-wakeup cycle is not zero, so there is a crossover point where staying awake slightly longer to batch work can be more efficient than waking repeatedly. The blog post "Racing to Sleep" covers this tradeoff in detail.
Peripheral state is the most common source of bugs around sleep modes. Entering a deep sleep while a UART transmission is still in progress, an ADC conversion is running, or an SPI CS line is still asserted can corrupt data or leave external devices in undefined states. Likewise, some devices require specific sequences to re-initialize clocks or PLLs on wakeup, which can be easy to overlook when code resumes from the instruction after the sleep entry call.
RAM and register retention rules differ across sleep depths and vendors. In the deepest modes (often called Standby, Hibernate, or Power-Down depending on the vendor), RAM contents may not be preserved, requiring firmware to save critical state to non-volatile memory or a small battery-backed retention RAM before entry. The distinction between "standby" and a full reboot can be subtle; the blog posts "Stand-by or boot-up" and "Boot sequence for an ARM based embedded system -2" discuss how to tell the difference and handle each case correctly.
Discussed on EmbeddedRelated
Frequently asked
What is the difference between sleep mode and a full power-off or reset?
In sleep mode the
MCU retains its
RAM contents and register state (up to a vendor-defined depth) and can resume execution in microseconds to milliseconds. A power-off or hard reset loses all
volatile state and requires a full boot sequence. Some deep sleep modes (Standby, Hibernate) blur this line by losing RAM but keeping a small amount of retention memory or
RTC state; the blog post 'Stand-by or boot-up' discusses how to detect which condition you are recovering from.
How do I choose which sleep depth to use?
Match the sleep depth to the slowest wake source you need. If you only need a periodic
RTC wakeup and no peripherals need to stay active, a deep stop or standby mode is usually appropriate. If you need the
UART or a fast timer to be able to wake the device, you are limited to a shallower mode where those clocks remain running. Measure actual current in each candidate mode with your specific peripheral configuration; datasheet numbers are typically for an ideal minimally-configured state.
Why does my device draw much more current in sleep than the datasheet specifies?
Common causes include
GPIO pins left floating or driving into resistive loads, peripherals (
ADC,
USB PHY, comparators) that were not explicitly disabled before sleep entry, external components on
I2C or
SPI buses that source or sink current through the
MCU's I/O pins, and
voltage regulators that remain in high-quiescent-current modes. The blog post '7 Essential Steps for Reducing Power Consumption in Embedded Devices' walks through a systematic checklist.
What is 'racing to sleep' and when does it matter?
Racing to sleep refers to the strategy of minimizing the time spent awake by processing events quickly and re-entering the lowest feasible sleep state immediately. It matters most when wake events are frequent relative to the processing time, because every microsecond spent awake at full-speed current costs energy. However, if clock startup and
PLL lock consume significant energy, batching work across a single longer wake window can sometimes be more efficient than many rapid wake-sleep cycles.
Does the CPU really stop executing immediately when I call WFI or enter a sleep mode?
On ARM Cortex-M cores, WFI halts the core pipeline at that instruction and the device enters the configured sleep state within a few cycles. On other architectures the exact
latency varies. One important caveat: if an
interrupt is already pending when the sleep instruction executes, many architectures (including Cortex-M) will take that interrupt immediately rather than sleeping, so firmware must account for this in critical-section designs around sleep entry.
Differentiators vs similar concepts
Sleep mode is one point on a spectrum of low-power states. Lighter modes (idle, wait) typically stop only the CPU clock while leaving most peripherals and
RAM active, giving fast wakeup at modest power savings. Deeper modes (stop, standby, hibernate, power-down -- naming varies by vendor) gate more clocks, power-gate more RAM, and can reach sub-microamp currents but impose longer wakeup times and may lose
volatile state. "Deep sleep" is often used informally to mean any of the deeper modes, but the exact definition is vendor-specific. Sleep mode should also be distinguished from a
watchdog-induced reset or a
brownout reset, both of which cause a full reboot rather than a resume.
