Making Sleep Modes Predictable Across All Subsystems

Modern embedded systems rarely “sleep” as a single unit anymore.

A connected device today is usually a collection of semi-independent subsystems working together continuously. There may be an application processor running Linux, one or more microcontrollers handling real-time control, sensors operating in low-power modes, external transceivers, PMICs, retention domains, always-on logic, and multiple voltage islands that behave independently.

On paper, low-power behaviour appears straightforward. Datasheets advertise microamp standby currents, deep sleep modes, wake-on-interrupt functionality, and autonomous peripheral operation. But in real products, predictable sleep behaviour becomes far more difficult than enabling a low-power register in firmware.

At Hoomanely, we learned that sleep architecture is fundamentally a coordination problem. The challenge is not putting one processor into standby. The challenge is ensuring that every subsystem in the product agrees on the transition at the same time, under all conditions, without creating leakage paths, undefined GPIO states, phantom wakeups, or partial-power conditions.

Especially in systems with cameras, sensors, CAN interfaces, external peripherals, level shifters, and multiple processors, sleep becomes a distributed system problem rather than a firmware feature.

Because once multiple power domains exist, “sleep” is no longer a single state. It becomes a carefully orchestrated system transition.

Sleep Failures Usually Come From Outside the MCU

Most low-power debugging sessions begin by questioning the processor. Engineers typically suspect that the MCU is not entering the correct standby mode, a peripheral clock is still enabled, DMA is active, or firmware failed to suspend properly.

But in many real systems, the processor is already sleeping correctly.

The leakage comes from everything around it.

A sensor interrupt line may be back-powering through an IO protection structure. A level shifter may still be partially enabled. A pull-up resistor connected to an always-on rail may be holding another subsystem alive. A transceiver may remain electrically active because one control pin never transitioned into a defined state.

The processor enters deep sleep successfully, yet the board current remains unexpectedly high.

This distinction is important because subsystem-level leakage cannot be solved purely in firmware. It is usually an architectural issue involving signal ownership, voltage-domain interaction, and power coordination between subsystems.

Leakage Current Is Often a Coordination Failure

One of the most misunderstood aspects of low-power design is that leakage current is frequently caused by coordination failures between domains rather than by the individual components themselves.

During design reviews, engineers often focus heavily on regulator quiescent current, sensor standby specifications, or processor sleep consumption. These values are important, but they assume ideal surrounding conditions.

Real leakage appears when multiple subsystems disagree about the electrical state of shared signals.

For example, a sensor domain operating at 1.8V may be powered down while the processor GPIO connected to it remains actively driven. An interrupt line may still have a pull-up connected to another voltage domain. A level shifter may continue to pass signals even though one side of the interface is no longer powered.

Now current begins flowing through unintended paths.

Sometimes the leakage is only a few microamps. Sometimes it is several milliamps. But more importantly, the behaviour becomes inconsistent. The leakage may vary with temperature, board revision, startup sequence, or firmware timing.

This is where predictable sleep behaviour starts failing. Not because one device is incorrect, but because the overall system lacks coordinated ownership of its interfaces.

Control Signals Quietly Become Power Rails

One of the most dangerous assumptions in low-power architecture is treating control signals as harmless logic lines.

In reality, many control signals behave like miniature power-distribution networks.

Signals such as ENABLE, RESET, WAKE, STANDBY, INT, and OE frequently cross voltage domains and power islands. They often connect always-on circuitry with power-gated subsystems.

Once this happens, the signal itself becomes a possible leakage path.

This is especially common in modular systems, mixed-voltage designs, and SOM-based architectures where one subsystem remains powered while another shuts down.

A sensor may appear “off,” while its reset pin remains driven through another active domain. A transceiver may continue leaking because its standby input is referenced to a powered rail. A level shifter may partially power an unpowered subsystem through internal structures.

The subsystem is no longer fully off. It is partially alive in an undefined state.

These failures are extremely difficult to debug because they often depend on timing and sequencing order. A board may behave correctly during one boot cycle and fail during another depending on which domain powers down first.

Sleep Must Behave Like a State Machine

Many systems implement sleep as a simple firmware operation:

enter_sleep();

Reliable low-power systems do not behave this way.

A predictable sleep architecture behaves more like a distributed state machine with strict sequencing rules.

Subsystems must quiesce in the correct order. Interfaces must enter defined states before regulators collapse. Wake sources must be validated before entering standby. GPIO ownership must transition cleanly across domains.

Without structure, sleep transitions become race conditions.

A sensor hub may disable clocks before interrupts are masked. A Linux processor may suspend while an external peripheral is still active. A wake interrupt may arrive before rails stabilise during resume.

Now wake behaviour depends entirely on timing.

And timing-dependent power bugs are among the hardest failures to reproduce consistently.

At Hoomanely, we treat sleep transitions as formal system states with clearly defined sequencing ownership rather than as isolated firmware events.

Wake Sources Require System-Level Coordination

Most low-power discussions focus heavily on entering sleep. In practice, coordinated wake behaviour is often the larger challenge.

Wake sources determine which domains remain powered, which clocks stay active, which interrupts retain authority, and which subsystem becomes responsible for restarting the rest of the system.

In multi-subsystem architectures, wake ownership becomes critical.

Should a sensor wake the main processor directly? Should a PMIC validate wake conditions first? Should wireless activity wake Linux immediately, or should a smaller always-on controller decide whether the wake event is important?

Without hierarchy and coordination, systems begin waking unnecessarily. Some enter repeated wake-sleep cycles. Others consume unpredictable amounts of power due to asynchronous wake interactions.

A poorly coordinated wake architecture can destroy battery life even if every individual component advertises excellent standby current.

The issue is not the component. The issue is the absence of a centralised wake strategy.

The Always-On Domain Must Stay Small

The always-on domain is one of the most dangerous areas in low-power architecture because it naturally expands over time.

Initially, the always-on section may contain only a wake controller and RTC. Then, additional requirements appear. Another interrupt source gets added. A debug signal is retained. A sensor monitoring path becomes persistent.

Eventually, the always-on domain becomes electrically noisy, difficult to reason about, and much harder to validate.

At Hoomanely, we aggressively minimise always-on ownership.

Not every subsystem deserves wake authority. Not every interrupt should persist during deep sleep. Not every signal should cross into retained domains.

Keeping the always-on section intentionally small improves predictability, simplifies validation, and reduces unexpected leakage paths.

The goal is not maximum flexibility. The goal is deterministic behaviour.

GPIO States During Sleep Are a Hardware Contract

GPIO behaviour during sleep is often treated as a firmware implementation detail.

In reality, GPIO state management is a hardware-software contract that directly affects leakage, wake stability, and subsystem behaviour.

Every externally visible signal should have an explicitly defined sleep behaviour. Some lines must retain state. Others must become high-impedance. Some require pull-ups or pull-downs. Some must remain wake-capable while others should become electrically isolated.

Undefined GPIO states are dangerous because the board-level outcome depends on external circuitry.

A floating signal may accidentally enable a regulator, oscillate near threshold voltage, create noise susceptibility, or partially power another subsystem.

These failures become even more problematic when external devices remain powered while the processor domain shuts down.

Now external peripherals may drive signals directly into sleeping silicon structures.

Predictable sleep behaviour requires explicit ownership of every signal during every power state.

Level Shifters Commonly Break Sleep Architectures

Level shifters are one of the most common hidden causes of sleep instability, especially automatic bidirectional translators.

These devices often behave correctly during normal operation while introducing subtle failures during power transitions.

They may remain partially active during rail collapse. They may leak current between domains. They may unintentionally back-power an unpowered subsystem through IO structures.

Many systems pass all normal functional testing yet fail only during suspend, wake, brownout, or hot-plug conditions.

The issue is rarely the level shifter itself. The issue is the lack of clearly defined domain ownership and sequencing rules around it.

Reliable low-power systems treat signal isolation as part of the sleep architecture itself.

Because an “off” domain is not truly off unless its interfaces are electrically isolated as well.

Transition Validation Matters More Than Static Measurements

One of the biggest mistakes in low-power validation is measuring only steady-state sleep current.

Many failures occur during transitions rather than during stable sleep itself.

Problems often appear during:

• suspend entry,
• asynchronous wake events,
• partial subsystem startup,
• delayed rail stabilisation,
• interrupted resume sequences,
• or external interaction during suspend.

Some systems appear stable only because testing accidentally follows the ideal timing sequence every time.

Real products never operate under ideal timing conditions continuously.

Interrupts arrive unexpectedly. External peripherals disconnect. Batteries droop. Users interact during transitions. Sensors assert wake requests asynchronously.

This is why robust low-power validation must include randomised transition testing, repeated suspend-resume cycles, delayed wake injection, partial subsystem failures, and noisy external conditions.

Predictable sleep behaviour is not proven by entering standby once successfully.

It is proven by surviving thousands of transitions consistently.

Predictable Sleep Is Ultimately About Ownership

The deeper lesson is that low-power reliability depends on clearly defined ownership boundaries.

Every subsystem must know:

• who controls power,
• who owns wake authority,
• who retains clocks,
• who may assert interrupts,
• and who defines resume order.

Without ownership clarity, leakage paths multiply, wake behaviour becomes nondeterministic, and debugging turns into timing-dependent experimentation.

At small scale, these issues appear manageable. At system scale, especially in connected edge devices with multiple processors and sensors, they become architectural failures.

Final Thoughts

Sleep modes are often presented as isolated hardware capabilities.

In reality, predictable low-power behaviour is a system-level engineering discipline.

The challenge is not simply putting a processor into standby. The challenge is ensuring that every subsystem transitions coherently, every signal remains electrically defined, leakage paths are structurally prevented, and wake behaviour is intentionally coordinated.

At Hoomanely, we treat low-power architecture as a distributed systems problem rather than a firmware feature.

Because modern embedded systems no longer fail due to the absence of sleep modes.

They fail because subsystems sleep independently without understanding each other.

And predictable low-power behaviour only emerges when the contracts between those subsystems are explicit, enforceable, and architecturally intentional.