IoT devices often need to save power. When the screen is off, the network is idle, or sensor sampling is infrequent, the system wants to enter a low-power state.
From the application point of view, sleep can look like “pause for a while and continue when an event arrives.” Inside the system, much more happens.
Device sleep is not just pausing the CPU. The system may stop CPU cores, lower frequencies, gate peripheral clocks, cut power domains, save register state, freeze user processes, run driver suspend callbacks, and leave only a small set of wake sources enabled.
A useful first model is: power management is a layered tradeoff between performance, response time, state retention, and power. The deeper the sleep state, the more power it saves, the more expensive wakeup becomes, and the fewer events can wake the system.
application becomes idle
-> kernel decides low power is allowed
-> drivers suspend
-> clocks and power domains are disabled
-> required wake sources remain active
-> external event arrives
-> power and clocks are restored
-> drivers resume
-> application continues
This path explains many symptoms: why UART bytes are lost during sleep, why Wi-Fi reconnects after wake, why timers drift, and why one GPIO can wake the system while another cannot.
Low-Power State Is Not One Thing
Devices usually have more than just “running” and “off.”
Common levels include:
- idle: CPU has no immediate work and enters a shallow sleep quickly
- clock gating: unused clocks are disabled
- power gating: selected modules lose power
- suspend to idle: software activity is largely frozen while hardware state is mostly kept
- suspend to RAM: CPU and many peripherals stop while memory self-refresh preserves RAM
- deep sleep / standby: only a small low-power domain and wake sources remain active
- power off: most state is lost and boot is required
Names differ by platform, but the tradeoff is the same: deeper states use less power, take longer to wake, and lose more state.
So any discussion of “device sleep” must first ask which sleep level is involved. Shallow sleep may only affect CPU scheduling, while deep sleep may require peripherals and network connections to be reinitialized.
Clocks and Power Domains Decide What Remains Alive
Not every module in an SoC uses the same power and clock.
CPU, SRAM, DDR, RTC, GPIO, UART, Wi-Fi, Bluetooth, sensor interfaces, and PMU blocks may live in different power or clock domains. When entering low power, the system chooses which domains stay alive and which are disabled.
That decides several key facts:
- which registers are lost
- which SRAM or retention RAM remains valid
- which peripherals can generate wake events
- which clocks keep running during sleep
- which drivers must reinitialize hardware after wake
For example, the RTC may remain in a low-power domain and can wake the system by time. A normal UART whose clock is disabled may not receive bytes during sleep unless the hardware has a dedicated wake-on-UART mechanism.
The application sees “the device slept.” The hardware sees many modules being stopped and restored in stages.
Wake Sources Must Be Configured Before Sleep
Before the system goes to sleep, it must know which events are allowed to wake it.
Common wake sources include:
- RTC timer
- GPIO edge
- button press
- charger insertion or removal
- network wake
- Bluetooth or Wi-Fi event
- sensor interrupt
- external MCU signal
Not every interrupt can wake a deeply sleeping system. Wake ability depends on whether the interrupt is connected to a low-power domain, configured as a wake source, and supported by clocks and power that remain active during sleep.
This explains common debugging results: a GPIO interrupt works while running but cannot wake from deep sleep; UART can wake shallow sleep but not deep sleep; RTC wakes the system while a normal timer cannot.
A wake source is not just an entry in the interrupt list. It is the result of power domains, clock domains, and interrupt controller configuration.
Driver suspend/resume Is Real State Management
During system sleep, the kernel asks drivers to suspend in order. After wake, it resumes them according to dependencies.
Driver suspend often needs to:
- stop new I/O requests
- wait for or cancel in-flight transfers
- save required register state
- disable DMA, clocks, and power
- configure wake sources
- place the device into a low-power mode
On resume, the driver restores clocks, power, registers, interrupts, DMA buffers, and device queues.
If the driver gets this state wrong, applications may see strange behavior:
- the first I/O after wake fails
- the device node exists but hardware is not restored
- DMA pointers or ring state are inconsistent
- interrupts were not reenabled
- sensor data remains stuck at pre-sleep values
- network devices need reauthentication or address renewal
So suspend/resume is not a pair of empty callbacks. It is part of the driver state machine.
Applications May Need to Prepare for Sleep
Sleep is not always transparent to applications.
On Linux desktop or server systems, system suspend freezes user processes and they continue after wake. On embedded devices, sleep and wake can still affect business logic:
- network connections drop
- sockets time out
- BLE or Wi-Fi must reconnect
- sensor sampling has a gap
- delayed timers run in a burst after wake
- file data may still be in Page Cache
- peripheral handles look unchanged while hardware was reinitialized
In RTOS or bare-metal systems, application tasks often participate more directly: deciding when sleep is allowed, which peripherals to shut down before sleep, and which state to restore after wake.
Applications need to distinguish state that the kernel and drivers can restore automatically from state that the business layer must rebuild.
The System Must Be Truly Idle Before Sleeping
Power-saving systems often fail in two ways: they should sleep but do not, or they sleep when they should not.
Failure to sleep often comes from a wakeup source, active reference, unfinished I/O, too many periodic timers, a driver blocking suspend, or an application creating frequent short timers.
Sleeping too early often comes from a critical transfer still running, file writes not synchronized, a peripheral still sampling, a protocol state machine assuming the connection remains valid, or business logic failing to declare that the system must stay awake.
Linux and Android systems use mechanisms such as wakeup sources, runtime PM, autosuspend, device links, and system suspend. They all answer the same question: who still needs the device to stay running, and who allows it to enter low power?
RTOS systems often have a power manager that looks at task idle state, peripheral state, and the next timer deadline, then chooses the deepest safe sleep state.
Sleep decisions are not just CPU idle percentage. They are about whether the system still has constraints that require it to stay awake.
runtime PM and System Suspend Are Different
System suspend puts the whole machine into a low-power state. Runtime PM lets an individual device enter low power while the rest of the system keeps running.
For example, the screen may be on and the CPU running, while an unused I2C sensor has its power or clock disabled. When the application accesses it again, the driver resumes that device.
The hard parts are reference counts and timing:
- who is currently using the device
- when the last user releases it
- how long autosuspend waits
- how long resume takes
- whether concurrent requests race with suspend
- whether parent and child device power dependencies are correct
If the reference count is wrong, the device may be powered off while still in use. If references are never released, the device never saves power.
Many intermittent I/O failures and “power never goes down” problems come from runtime PM state machines.
Low Power Changes Debugging
Low-power bugs are hard to debug because observation can change behavior.
With a debugger attached, the device may not enter deep sleep. Enabling serial logs may keep the UART clock alive. Frequent logging keeps the CPU busy and hides real power behavior. Oscilloscopes, power meters, GPIO trace pins, RTC timestamps, and event records in retained RAM are often more reliable than ordinary logs.
Split low-power problems into categories:
- cannot enter sleep: who holds a wakeup source or active reference
- sleeps and wakes immediately: which wake source fired
- cannot wake: power domain, clock, or wake-source configuration is wrong
- fails after wake: driver resume or application reconnect logic is broken
- power is too high: some peripheral, clock, or power domain remains enabled
Application logs alone often miss the real cause.
How to Debug Sleep and Wake Problems
When debugging power-management issues, split the path into layers.
First, identify the low-power state: idle, shallow sleep, suspend to RAM, deep sleep, or power-off reboot.
Second, identify which power domains and clocks remain active during sleep. RTC, GPIO, memory, peripherals, and wireless modules may differ.
Third, check wake source configuration. An interrupt working while running does not prove it can wake from deep sleep.
Fourth, check driver suspend/resume. Registers, interrupts, DMA, queues, and device state must be restored correctly.
Fifth, check whether application state must be rebuilt. Network connections, sockets, sensor sampling, file persistence, and timers may be affected.
Sixth, check whether debugging changed power behavior. Logs, debuggers, serial ports, and measurement tools can keep the system awake.
These questions locate the right layer better than only saying “sleep is broken.”
What Matters in Practice
Power management is not a switch. It is a set of layered state transitions.
During sleep, CPU, clocks, power domains, peripherals, memory, wake sources, drivers, and application state all participate. The deeper the sleep, the lower the power, the higher the recovery cost, and the less state can be kept.
Low-power design should separate:
- which state must be retained
- which peripherals may be powered off
- which events must wake the system
- which drivers must save and restore hardware state
- which application connections or business state must be rebuilt
The application sees “the device slept and woke up.” The system actually performs a coordinated transition across hardware, kernel, drivers, and business state.