8 Low-Power Design: Sleep-State Energy Accounting

8.1 Start With the Decision

A firmware team has reduced active time and selected a deep-sleep state.

8.2 Route Overview

This is part 1 of 2. Continue with Low-Power Design: Leakage and Body Bias.

8.3 Part Objectives

• Measure deeper sleep is not always cheaper from current, time, and transition evidence.
• Choose a defensible design using worked cc2650 state selection.

8.4 Start With the Situation

A firmware team has reduced active time and selected a deep-sleep state. The current trace still misses its target because wake energy, pull-ups, clocks, and powered peripherals remain outside the simple sleep-current number. The team now needs a whole-state ledger.

8.5 Overview

This route compares sleep states by total energy, finds hidden leakage paths, and applies the same ledger to clocks, radios, and nanowatt front ends.

This is part 2 of 2. Review Low-Power Design: Policy, Gating, and Firmware when you need the first route.

8.6 Learning Objectives

By the end of this chapter, you will be able to:

• calculate when a deeper sleep state actually saves energy
• identify leakage paths that bypass a power-gated load
• compare clock, radio, and front-end choices with a whole-state current ledger

8.7 Chapter Roadmap

• Start With the Situation
• Overview
• Deeper Sleep Is Not Always Cheaper
• What Each Mode Trades
• Sleep current
• Retention
• Wake cost
• Peripheral rails
• Overview Knowledge Check
• Find The Sleep-Depth Break-Even
• Worked Example: Light Sleep Versus Deep Sleep
• Sleep Strategy Ledger
• Practitioner Knowledge Check
• Hidden Leakage Paths Defeat Power Gating
• Leakage Paths To Close Before Sleep
• Pull-ups into gated chips
• Enabled clocks
• Driven-into loads
• Floating inputs
• Under-the-Hood Knowledge Check
• Practitioner Bridge: Ultra-Low-Power Front Ends
• Worked 1 nW Average Front-End Budget
• Peripheral Clock-Current Budget
• Worked Radio-MCU Mode Ledger
• Worked CC2650 State Selection

8.8 Deeper Sleep Is Not Always Cheaper

Low-power design is often summarized as "sleep as deep as possible," but that advice is incomplete. Each sleep mode trades three things at once: how little current it draws, how much state it retains, and how long and how expensively it takes to wake. A deeper mode draws less current but keeps less state, so waking from it costs more energy to restore or reboot. That wake overhead means there is an optimal sleep depth, and it depends on how often you wake.

On a typical processor, a light sleep might draw around 0.8 mA while retaining RAM and peripherals for an almost instant wake, whereas a deep sleep might draw around 10 uA but keep only a real-time clock, forcing a full boot and re-initialization on wake. If you wake often, the repeated boot cost can exceed everything the deeper floor saved.

The practical question in deeper sleep is not always cheaper is where Active Mode hands responsibility to Power. Use Figure 8.1 to inspect that hand-off before carrying the design forward.

The visual path in Figure 8.1 moves from Active Mode (adds a distinct review condition) through Power (exposes the energy consequence) to 20 - 240 mA (adds a distinct review condition). Reading those labels as one chain clarifies that active, light sleep, and deep sleep mode comparison showing current range, wake latency, retained state, peripheral state, and best use case. It therefore connects this diagram directly to the chapter’s treatment of deeper sleep is not always cheaper.

Use the comparison as a review prompt. A device that samples once per hour can usually afford a cold wake, rebuild state, and pay the boot cost. A device that wakes every few seconds to debounce a button, watch a threshold, or maintain a short receive window may spend more charge repeatedly restarting than it would have spent staying in a lighter retained mode. The correct choice is the mode with the lowest measured charge over the whole interval, including state restore, sensor settling, clock startup, bus configuration, and radio rejoin.

8.9 What Each Mode Trades

8.14 Overview Knowledge Check

8.15 Find The Sleep-Depth Break-Even

Compare the two modes over a sleep interval T. Light sleep costs about Ilight x T. Deep sleep costs Ideep x T plus a fixed wake energy Ewake for the reboot. Deep sleep wins only when its lower floor has had enough time to repay the wake cost.

8.16 Worked Example: Light Sleep Versus Deep Sleep

Light sleep draws 0.8 mA with a negligible wake. Deep sleep draws 10 uA but needs a 250 ms boot at 40 mA, so Ewake = 40 mA x 0.25 s = 10 mA-s. Setting the two equal: 0.010 x T + 10 = 0.8 x T gives T = 10 / 0.79 = 12.7 s.

• Wake every 5 s: light = 0.8 x 5 = 4.0 mA-s; deep = 0.010 x 5 + 10 = 10.05 mA-s. Light sleep wins by about 2.5x.
• Wake every 60 s: light = 0.8 x 60 = 48 mA-s; deep = 0.010 x 60 + 10 = 10.6 mA-s. Deep sleep wins by about 4.5x.
• Break-even: near 13 s. Below it, the boot overhead makes deep sleep more expensive; above it, the low floor pays off.

Then handle the peripherals. A sensor drawing 1 mA left powered through a 60 s sleep leaks 1 x 60 = 60 mA-s per cycle - a hundred times the 0.6 mA-s the processor's deep sleep uses. Power-gating that sensor, at the cost of a small re-power and settle on wake (say 2 mA for 20 ms, 0.04 mA-s), removes almost all of that leak.

8.17 Sleep Strategy Ledger

8.18 Practitioner Knowledge Check

8.19 Hidden Leakage Paths Defeat Power Gating

Power-gating a peripheral only helps if you cut every path into it. A classic trap involves the I2C bus. Suppose you switch off a sensor's power rail to save its 1 mA during sleep, but leave the bus pull-up resistors powered and the I2C lines high. Current then flows from the pull-ups through the sensor's input protection diodes into the now-unpowered chip. That leak both wastes current and can partially power the sensor through its own pins, so the gated device is neither fully off nor properly saving energy.

The same pattern hides in other places: a peripheral clock left enabled keeps a block toggling, a GPIO left driving into a depowered load pushes current through protection structures, and a floating input can oscillate and draw switching current. The fixes are specific and cheap. Before sleeping, drive shared bus lines low or gate the pull-ups on the same switch as the sensor, disable unused peripheral clocks, and set unused pins to a defined low-leakage state. The rule is to power-gate the whole island - rail, pull-ups, and signals together - not just the chip's main supply pin.

Put a number on the hidden path before dismissing it. A 4.7 kOhm pull-up on a 3.3 V bus can source about 3.3 / 4700 = 0.70 mA if a depowered input clamps the line low through a diode path. Two lines can therefore create a milliamp-scale leak, larger than many MCU deep-sleep currents by two orders of magnitude. Even a partial 0.2 mA leak on each line for a 60 s sleep interval adds 0.4 x 60 = 24 mA-s, which dwarfs the 0.6 mA-s of a 10 uA processor sleep over the same interval. The measurement proof is simple: change the bus state, gate the pull-ups with the sensor rail, and confirm the sleep floor falls in the full-cycle trace.

8.20 Leakage Paths To Close Before Sleep

8.25 Under-the-Hood Knowledge Check

8.26 Practitioner Bridge: Ultra-Low-Power Front Ends

The system-level sleep ledger eventually reaches the analog front end. At nanowatt-scale average power, the sensing circuit’s leakage, reference, timer, bias network, and conversion events can cost more than the processor. This is also where practitioner and chip-design depth must be separated: a board designer can select, duty-cycle, isolate, and measure a front end, while transistor sizing, body-bias generation, chopper switch design, and SAR capacitor switching belong to an analog-IC design and verification flow.

Use this bridge as a stop rule. If a catalog front end clears the whole-device energy and accuracy budget, keep the design at practitioner depth. Move into custom analog design only when the product volume, sensing limit, and measured shortfall justify the extra process, verification, reliability, and lifecycle work.

8.28 Peripheral Clock-Current Budget

“Lower the clock” is only useful after separating clock-source current from the current switched inside each peripheral. A first-order ledger is

where $f_s$ is the oscillator frequency, $f_i$ is the clock delivered to peripheral $i$, and $k_i$ is its measured current-per-frequency slope. Clock division reduces the $k_if_i$ term for the divided domain; it does not make the parent oscillator draw as though it were running slowly.

One historical MCU example reported these clock-source operating points:

The same example used approximate peripheral slopes of 8.5 $\mu$A/MHz for a UART and 1.9 $\mu$A/MHz for SPI. If a 12 MHz RCFAST source is already required elsewhere but both peripherals need only 1 MHz, a divide-by-12 branch gives the required peripheral clock. Their frequency-dependent contribution is then

Including the still-running RCFAST source gives about 190.4 $\mu$A before peripheral baselines, CPU, memory, and load current. If no other domain needs 12 MHz and RC1M satisfies every timing constraint, selecting it instead would make the same illustrative subtotal $35+10.4=45.4\ \mu$A. The divider is a large improvement over clocking both peripherals at 12 MHz, but turning off the unnecessary fast parent is better.

Do not select the divider from current alone. A UART typically needs a clock high enough to generate and oversample the requested baud with acceptable error; SPI must meet minimum high/low times and transaction deadlines. Calculate the slowest valid peripheral clock, verify divider and mux register fields against the actual datasheet, wait for clock-ready status before switching, and measure the full transaction. A clock that halves current but doubles active time may leave energy unchanged.

8.29 Worked Radio-MCU Mode Ledger

Radio current spans orders of magnitude, so a linear average must be built from time in each mode. One wireless-MCU profile reported approximately 0.7 $\mu$A in deep sleep, 4.1–4.7 mA in shallower sleep or transceiver-off modes, 10.1 mA receive with reduced-power cycling enabled versus 16.6 mA without it, and 18.6 mA during busy transmit. Supply voltage, temperature, RF settings, and silicon revision affect these historical values; use them to learn the ledger, then replace them with measured target data.

Before reading the mode table, look at Figure 8.2, which plots these same currents on a logarithmic axis. A linear chart would render deep sleep invisible; the log scale is the only honest way to fit a 0.7 $\mu$A floor and an 18.6 mA transmit peak in one picture.

In Figure 8.2 the Deep sleep bar barely leaves the axis while Busy transmit reaches almost five decades further right, and the dashed annotation marks every awake mode as at least 5,800 times the sleep floor. The lower panel then replays this section’s one-hour schedule: Where the hour goes is a nearly solid block of deep sleep, yet Where the charge goes hands roughly three quarters of the 32.3 mC total to receive windows. Keep both strips in mind while working through the exact ledger below.

For a target below 10 $\mu$A with deep sleep and receive only, the maximum receive duty factor is

That is only 3.32 seconds of receive time per hour. A concrete schedule can fit more than one state: receive for 20 ms every 30 s and transmit for 5 ms every 60 s. In one hour this gives 2.4 s RX, 0.3 s TX, and 3,597.3 s deep sleep. The idealized average is

Only 1.02 $\mu$A remains for wake transitions, sensing, CPU work, regulator quiescent current, retries, and leakage, so this schedule is not yet a release design. It demonstrates why the logarithmic-looking mode spread matters: milliseconds in receive can consume more charge than many minutes of deep sleep.

8.30 Worked CC2650 State Selection

A CC2650-class historical mode table makes retention choices concrete:

At 48 MHz, the active-core model gives

A 151 $\mu$s standby-to-active transition consumes more than

clock periods. Approximating the transition at the active current gives 0.444 $\mu$C, or about 1.33 $\mu$J at 3 V, before useful instructions. That fixed wake term is why batching several tasks behind one wake can save more energy than shaving a few cycles from each task.

Retention uses more sleep current but may avoid cache refill or reinitialization. Compare two states over sleep duration $T$:

If cache retention costs an extra 1.7 $\mu$A but avoids 1,500 active cycles at 48 MHz, the avoided active charge in this simplified model is

The break-even sleep interval is $91.8$ nC$/1.7\ \mu$A\approx54$ ms. With shorter sleeps, retention wins in this hypothetical workload; with longer sleeps, the lower-current state wins. Replace 1,500 cycles with a trace from the actual firmware, include oscillator and regulator transitions, and repeat at the required temperature.

The whole selection argument compresses into Figure 8.3: a ladder of states priced in current and retained resources, plus a strip that turns the 54 ms result into a usable rule of thumb.

Reading the ladder top-down, Radio RX / TX and Active, 48 MHz are the only rows above a milliamp, while both Standby rows hold microamp floors with RTC, CPU and RAM intact; the amber banner restates the 151 $\mu$s $\approx$ 7,248-cycle wake toll paid before the first useful instruction. On the break-even strip, sleep intervals left of the 54 ms mark belong to retain cache, longer ones to drop to plain standby — exactly the boundary the charge comparison above computed.

8.31 Continue to the Next Part

Carry this evidence into Low-Power Design: Leakage and Body Bias, which begins with Subthreshold Slope and the Leakage-Speed Trade.