Low-Power Design

• Target devices often run from CR2032 (225 mAh) for 5–10 years, or harvest μW-scale energy from solar/vibration.
• The CPU is frequently awake < 1% of the time — everything depends on low-power idle.
• Cortex-M spec provides a small set of architectural primitives: WFI, WFE, SLEEPDEEP, SLEEPONEXIT.
• Vendors layer their own power modes (STOP, STANDBY, LPM, SYSTEMOFF, HIBERNATE) on top of those primitives.
• Interview angle: articulate the split between what Arm standardises and what the SoC vendor adds.

Regular Sleep

• SCB->SCR.SLEEPDEEP=0.
• Core & NVIC clock gated; most peripherals keep running.
• Wake latency: < 10 cycles.
• Typical current: 500 μA – 5 mA depending on how much of the SoC stays up.

Deep Sleep

• SCB->SCR.SLEEPDEEP=1.
• Architecture only says "deeper" — the vendor defines what goes off (PLL, flash, analog, SRAM retention).
• Wake latency: μs to ms.
• Typical current: 0.3 – 10 μA.

void enter_deep_sleep(void)
{
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
    __DSB();
    __WFI();
    /* on wake, clock tree restarts;
       code continues here */
}

• The WIC duplicates the NVIC's mask logic on a tiny always-on domain (~100 nA).
• In deep sleep, the core and NVIC are clock-gated or power-gated. Their outputs are Xs electrically.
• The WIC listens to the always-on IRQ lines; on any masked-in assertion, raises WAKEUP to the PMU.
• PMU restarts clocks → CPU wakes → NVIC re-captures the IRQ → handler runs normally.
• Without the WIC, you cannot power-gate the NVIC and keep IRQ wake; getting down to sub-μA requires WIC support.

What can be retained in sleep

• CPU state — GPRs, xPSR, SP, control — stored in a handful of retention flops on the always-on domain (auto-handled by the core in some sleep modes).
• NVIC state — priorities, pending/enabled masks.
• SRAM — "retention SRAM" banks can be kept powered while the rest is collapsed. STM32 typically has 1–4 retention banks configurable.
• Backup registers — a handful of 32-bit words on the VBAT/RTC domain, persist across the CPU powering off entirely.

What you give up per level

• Classical RTOS wakes every 1 ms via SysTick → thousands of useless wake-ups per hour.
• Tickless: replace fixed SysTick with an RTC-driven timer. Scheduler programs the next needed wake directly.
• Requires:
  • Idle callback: "sleep for up to N ticks".
  • Vendor RTC / low-power timer with a 32 kHz xtal.
  • On wake, correct the tick count by elapsed RTC time.

/* FreeRTOS: enable tickless */
#define configUSE_TICKLESS_IDLE          1
#define configEXPECTED_IDLE_TIME_BEFORE_SLEEP 2

/* Vendor overrides vPortSuppressTicksAndSleep
   to replace SysTick with RTC-WUT */
extern void vPortSuppressTicksAndSleep(TickType_t);

/* Pseudo-flow in the port */
void vPortSuppressTicksAndSleep(TickType_t xExpected)
{
    rtc_program_wake(xExpected);
    enter_stop_mode();        /* SLEEPDEEP + WFI */
    TickType_t slept = rtc_elapsed_and_clear();
    vTaskStepTick(slept);
}

• Cortex-M itself has no DVFS table — frequency/voltage scaling is entirely the SoC's job.
• Typical scheme:
  • Boot at slow HSI (internal oscillator, e.g. 16 MHz).
  • Enable PLL → run at 80 / 100 / 168 MHz during active work.
  • Drop back to HSI before WFI.
  • Scale V_core via a vendor VOS register (STM32: PWR_VOS0..VOS3).
• Changing voltage is slow (ms). Changing clock source is fast (μs). The ratio drives most workflows.

• Every Cortex-M SoC has "RCC / CMU / CKG" registers — one enable bit per peripheral clock branch.
• A disabled peripheral draws leakage only — sometimes a couple of nA.
• Correct pattern:
  1. Clock-gate peripheral.
  2. Touch its registers → vendor-defined behaviour (STM32: reads RAZ, writes WI until clock re-enabled).
• In RTOS, attach a "peripheral use-count" on each clock branch: enable on first user, disable on last.

/* STM32H7 — enable then disable UART2 clock */
RCC->APB1LENR |=  RCC_APB1LENR_USART2EN;
__DSB();
/* … work with UART2 … */
RCC->APB1LENR &= ~RCC_APB1LENR_USART2EN;

/* Nordic nRF52 — per-peripheral in PMU */
NRF_UARTE0->ENABLE = UARTE_ENABLE_ENABLE_Disabled;

The clock-gate bit is not the same as the peripheral-enable bit. Both are usually necessary.

• System ON — normal running; idle via WFI. SoC automatically gates peripherals whose owner driver has disabled them. Typical: 5–20 μA with RTC + BLE PHY off, few kHz from the RTC.
• System OFF — SoC powered down apart from RAM retention + RESET/WAKEUP pins. ~0.4 μA.
• Constant-Latency submode — forces HFCLK running; avoids PLL restart jitter for audio or radio.
• Radio (PHY + baseband) & TIMERs are part of the power-aware event-driven architecture — PPI (Programmable Peripheral Interconnect) lets them operate without CPU wake.

• Ambiq Apollo family runs the Cortex-M core at V_core ≈ 0.5 V — below the classical threshold voltage.
• Requires custom SRAM & flash designed to operate at that voltage, plus variation-tolerant logic libraries.
• Result: ~6 μA/MHz active (Apollo4 Plus, 2022), vs 40–80 μA/MHz for conventional silicon on the same process.
• Clock typically 96–192 MHz — subthreshold imposes a speed ceiling.
• Used in Apple Watch S8 onwards (M4 Apollo3 Blue Plus derivative) and countless hearing aids / fitness bands.

• ULPMark-CP (Core Profile) — wakes the MCU for 1 s of "light" work, sleeps 9 s, repeats. Measures energy per 1000 work-cycles.
• ULPMark-PP (Peripheral Profile) — exercises analog and digital peripherals in a realistic IoT duty cycle.
• ULPMark-SP — security primitive profile (AES, SHA, RNG).
• Vendor datasheets quote these heavily because pure μA/MHz is only half the story — how quickly you can get to sleep matters just as much.

• Same CoreMark integer benchmark as everywhere, divided by measured active current.
• Rewards fast-finishing cores with low μA/MHz.
• An M7 at 480 MHz can beat a 32 MHz M0+ on CoreMark/mA — because although it draws more current, it finishes in 15× less time.

• Entering deep sleep gates the DAP clock — debugger link drops.
• Vendor "debug-monitor" bits keep the DAP alive in sleep modes for development:
  • STM32: DBGMCU_CR.DBG_STOP = 1, DBG_STANDBY = 1.
  • Nordic: POWER_DEBUG.ENABLE.
  • NXP: DEBUG_SAFE bit.
• Note: enabling these disables the sleep power reduction. Power measurements must be done with debug-in-sleep disabled.

• Joulescope JS110 / JS220 — 15-bit μA .. A dynamic range, captures sleep-to-active transitions.
• Keysight N6705 / N6785A — bench SMU with waveform logging.
• Qoitech Otii / Nordic PPK2 — purpose-built MCU current profilers with UART side-channel.
• DWT CYCCNT + a logic analyzer — cheap way to correlate firmware state with external measurement.

Sensor wakes every 1 s, samples ADC for 5 ms, then deep-sleeps.

Average current:

I_avg = (0.005 × 8000 + 0.995 × 2) / 1.000
      = 40 + 1.99 μA
      ≈ 42 μA

CR2032 @ 225 mAh →

life = 225 mAh / 0.042 mA
     = 5357 h
     ≈ 7.4 months

If we cut the active time to 2 ms (faster clock, pre-triggered ADC via DMA + PPI):

I_avg = (0.002 × 8000 + 0.998 × 2) / 1
      ≈ 18 μA

life = 225 / 0.018 = 12500 h ≈ 1.4 years

• Explain the difference between WFI and WFE and when each is correct.
• Describe the role of the WIC — why it's needed for sub-μA sleep.
• Walk through a tickless RTOS sleep: programming RTC, entering STOP, recovering the tick count.
• Justify "race-to-sleep" vs "race-to-idle" in two sentences, specific to a given SoC generation.
• Give 3 reasons a power trace might show unexpected active μA you didn't intend.

• Know which SoC registers freeze watchdogs & timers on halt (DBGMCU_CR / PMU).
• Explain how SLEEPONEXIT interacts with main() — and why some codebases never use main() at all.
• Describe how Nordic / STM32 / Ambiq each layer extra sleep states on top of the Cortex-M primitives.
• Know EEMBC ULPMark-CP vs -PP — what's measured, why they differ.
• Compute a CR2032 battery life from duty cycle & active current.