Low-power firmware techniques for battery-powered MCUs

• Map the MCU power domains and on-board regulators
• Cut active-mode burn: clock scaling, voltage trimming, and peripheral gating
• Choose sleep modes and design reliable wake paths (RTC, GPIO, radio)
• Retain state and resume cleanly: retention RAM, peripheral gating, and sequencing
• Measure, validate, and iterate: current measurement and power budgets
• Practical checklist: low-power bring-up and verification protocol

Low-power firmware is not a checklist item you tack on at release; it is the fundamental system design choice that determines whether a battery-powered product lives in the field for months or for years. The techniques below are the ones that actually move the needle in production devices — not vague tips, but the concrete hardware- and firmware-level moves that survive manufacturing variance and real users.

The problem you face is always the same: the datasheet and the lab disagree, intermittency bites you (spurious wakeups or silent drains), and a few peripherals or a poor regulator choice erase your battery margin. You see symptoms such as wildly different battery-life estimates between bench and field, bursty current spikes at wake/resume, RTC drift that creates extra wake events, and long recovery sequences that force the MCU to run longer than expected. Those are firmware–hardware interface failures, and they are fixable if you treat power as an orchestration problem instead of a single setting.

Map the MCU power domains and on-board regulators

Start by building a clear map of where power lives on your board. A minimal map has:

• Always-on / VBAT domain (RTC, backup registers).
• Core domain(s) that supply CPU and core SRAM (often supplied by an internal/external buck or LDO).
• I/O / analog domain(s) for ADCs, comparators, USB transceivers, sensors.
• Any external power switches, load switches, or battery fuel gauges.

Many modern MCUs expose internal power islands and an on-chip switching regulator or selectable buck/LDO for the core — read the electrical sections and the "Power, Reset and Clock" chapter in the datasheet for exact domains and retention behaviour. Examples of on-chip regulator options and retention features appear in contemporary MCU families (embedded buck/LDO, VBAT domains and RAM retention).

Why this matters: power domains define what you can truly turn off. A domain that can be power-gated (off) saves leakage; a domain that only supports clock-gating saves dynamic power but still draws leakage. Treat the regulator topology (external buck, LDO, or on-chip SMPS) as part of the firmware story because switching the MCU into a low-voltage performance level without coordinating the regulator and flash wait-states can brick timing and flash access.

Quick checklist (first pass)

• Find the datasheet sections: Power, Reset, Low‑Power Modes, and Electrical Characteristics. Mark VBAT, backup SRAM, and regulator options.
• Identify the external parts: battery chemistry, protection IC, charger, external buck/LDO, and any load switch.
• Confirm what the MCU retains in each low-power mode (backup registers, backup SRAM, partial SRAM retention).
• Note wake-source availability per mode (GPIO, RTC, EXTI, radio, comparator).

Important: map the real board (circuit schematic) to the datasheet picture. A regulator on the board may nullify an on‑chip SMPS advantage unless you change the hardware.

Cut active-mode burn: clock scaling, voltage trimming, and peripheral gating

Dynamic power is where you get the biggest wins quickly: Pdynamic = α · C · V² · f, where α is switching activity, C the capacitance, V the supply voltage and f the clock frequency. Reduce voltage for quadratic gains; reduce frequency for linear gains.

Practical levers

• Clock scaling: move high-frequency domains to slower clocks for non-time-critical tasks; run the CPU at the minimum frequency that meets real-time deadlines. On Cortex‑M devices, the architecture explicitly supports clock gating and controlled deep-sleep (SLEEP / SLEEPDEEP) so that gating the HCLK or other bus clocks reduces dynamic switching inside the silicon. Apply the gating at the peripheral/clock controller level, not by spinning NOPs.
• Voltage trimming / DVFS: where supported, use lower performance/voltage points for background or periodic tasks. Beware: flash wait-states, peripheral timing, and ADC sampling parameters change with regulator/voltage settings — sequence these transitions (reduce frequency, change flash wait-states, then reduce voltage). Some family-specific "Low-power Run" modes exist that tie regulator behaviour to permitted clock rates.
• Peripheral gating: disable clocks to unused peripherals (APB/AHB clock enables), stop DMA channels and put serial peripherals in low-power modes. Hardware clock gating prevents switched capacitance inside the peripheral and stops it from generating bus traffic.

Concrete, minimal example (pseudocode style—check your MCU's register names):

// reduce system frequency safely (pseudocode)
disable_interrupts();
prepare_flash_for_lower_freq();   // adjust wait states per datasheet
switch_system_clock_to_hsi();
set_pll_divider(new_div);        // lower freq
wait_for_pll_lock();
update_SystemCoreClock();
enable_interrupts();

// gate unused peripheral clocks
PERIPH_CLK_EN_REG &= ~(1 << UART1_CLK);
PERIPH_CLK_EN_REG &= ~(1 << SPI2_CLK);

Contrarian, real-world insight: aggressively slowing the core is not always better. For many tasks the cheapest energy per operation occurs by running faster at slightly higher instantaneous power and returning the chip to deep sleep sooner. Always evaluate energy per task rather than instantaneous current. Use the energy model: E_task = P_active · t_active. Lower t_active can offset higher P_active.

When to implement run-time scaling vs build-time choice

• Use run-time scaling when workload varies and you can predict deadlines.
• Use fixed low-speed operation for extremely simple data-loggers with tiny task sets.

Source notes: dynamic power behaviour is well-established in CMOS design and explained in comprehensive references. Clock gating and sleep semantics are described in Cortex reference documentation.

Choose sleep modes and design reliable wake paths (RTC, GPIO, radio)

Pick the deepest sleep mode that supports the wake sources you need. Vendors typically expose a spectrum of levels: light Sleep (core halted; peripherals active), Stop/DeepSleep (clocks off; some peripherals or low-speed oscillators preserved), and Standby/System-off/Shutdown (most domains off; only VBAT/RTC or wake pins remain). Typical numbers for modern ultra-low-power MCUs show Run-mode tens–hundreds of μA/MHz, Stop modes in the single-digit μA to sub-μA range, and Standby down to nanoamperes — review the device product page for exact figures.

Wake-source engineering

• RTC wakeups: use a 32.768 kHz external crystal (LSE) if accuracy and low drift matter; LSE typically stays on in many stop modes and is the lowest-power accurate clock for RTC. Ensure the RTC source and prescalers are sized to minimize wake overhead and drift.
• GPIO / WKUP pins: wire wake pins with defined levels and use external hardware debouncing or comparator filters for noisy inputs; floating lines cause spurious wakes.
• Radio / wake-on-radio: many wireless radios support low-power “wake-on-radio” or “listen” modes; decide whether the MCU must remain in system-on or can be woken by the radio MCU. Architect the radio-MCU interaction such that the MCU sleep mode matches radio wake capability.
• Peripheral-driven wake (SleepWalking): some MCUs support peripherals that run while CPU sleeps and only wake the CPU on a qualified event (ADC threshold, UART address match). Use this when realistic; it dramatically reduces unnecessary wakeups.

Sleep mode summary (typical; verify in your datasheet)

Mode	Retains RAM	Typical wake sources	Typical current (order)	Wake latency
Sleep / Idle	Yes	Any interrupt	mA → 10s μA	μs
Stop / DeepSleep	Yes (partial/full)	RTC, EXTI, some peripherals	μA → 10s μA	10s μs → ms
Standby / Shutdown	No (VBAT/backup retained)	RTC (VBAT), WKUP pins	sub-μA → nA	ms → tens of ms

Example: configure a periodic RTC wakeup on STM32-style HAL:

// example for periodic wakeups (check your HAL)
HAL_RTCEx_DeactivateWakeUpTimer(&hrtc);
HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, seconds, RTC_WAKEUPCLOCK_CK_SPRE_16BITS);

Use the vendor app notes for precise register sequences and to understand which oscillators remain alive in each mode.

Retain state and resume cleanly: retention RAM, peripheral gating, and sequencing

Design a deterministic suspend-resume path. Losing state across deep sleep is acceptable if you plan for it; retention RAM and backup registers exist for a reason. Decide the minimum saved context (time, counters, last ADC sample) and put that in backup or retention memory so the wake path is fast and deterministic.

Suspend sequence template

1. Disable high-frequency interrupts and timers that will cause spurious wake. Mask NVIC lines you know are noisy.
2. Stop or drain DMA transfers and ensure memory writes complete.
3. Save minimal runtime state to retention memory or battery-backed registers.
4. Disable peripheral clocks (or set peripherals to Run‑in‑Standby appropriately).
5. Clear and configure wake-status flags (peripheral flags, EXTI pending, RTC flags).
6. Enter sleep/stop/standby (WFI/WFE or vendor-specific call).

Resume sequence (reverse, but validate)

1. On wake, re-enable base oscillators and wait for stability if required (PLL, HSE).
2. Restore clock tree and flash wait-states before touching peripherals that require the new clock frequency.
3. Re-enable peripheral clocks and reinitialize (or validate) peripheral state.
4. Re-arm DMA, re-enable interrupts.

Example suspend/resume skeleton:

void system_suspend(void) {
  __disable_irq();
  flush_and_stop_dma();
  save_minimal_state_to_backup();
  disable_unused_peripheral_clocks();
  clear_wakeup_flags();
  HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);
  // MCU sleeps...
  // on wake:
  SystemClock_Config(); // restore clocks and flash wait-states
  restore_peripheral_clocks();
  restore_state_from_backup();
  __enable_irq();
}

Watch for hazards:

• Resuming before PLLs lock or flash is ready yields hard faults or corrupted reads.
• Peripheral register contents are often lost in deep-power domains — don't rely on implicit retention.
• "SleepWalking" designs let peripherals do small jobs without waking the CPU but can add complexity to power domain transitions; use vendor documentation and examples (SAM L and similar families have explicit SleepWalking power-domain handling).

Measure, validate, and iterate: current measurement and power budgets

You must instrument the system: datasheet numbers are starting points; bench numbers are reality. Use a test rig that can capture both average current and fast spikes.

Recommended toolset

• Power analyzer / DAQ (Qoitech Otii Arc, Monsoon Power Monitor, Keysight power analyzers) for high-resolution energy-per-event and long-term logging. These tools give trace correlation and scripting.
• Oscilloscope + current probe for visualizing spikes and wake transients.
• Shunt resistor + high‑speed ADC or DAQ when you want a cheap but accurate solution for bursts.
• Development board power monitors / X-NUCLEO-LPM01A / ST-LINK monitor for quick checks.

Measurement methodology

1. Put the device into the exact sleep configuration you plan to ship with. Measure steady-state sleep current over many cycles (minutes) to average out timer jitter.
2. Trigger a single active cycle and capture the energy per event (integrate current × time during active window). Do this at target operating voltage. Repeat dozens of times and average.
3. Compute average current for your duty cycle:

I_avg = (E_active / T_period) / V + I_sleep

or equivalently:

I_avg = (I_active * t_active + I_sleep * (T_period - t_active)) / T_period

1. Convert to battery life: Battery_hours = Battery_mAh / I_avg.

Measurement example (numeric)

• Active: 10 mA for 100 ms every 60 s → contribution = (10 mA * 0.1 s) / 60 s = 0.0167 mA average.
• Sleep current: 2 μA → total ≈ 0.0187 mA.
• With a 1000 mAh battery → ~53,475 hours (~6.1 years) under ideal conditions (real-world inefficiencies will lower this).

Practical tips learned in the field

• Use a GPIO toggle to mark critical code sections in the power trace (toggle a pin before/after sensor read) so you can correlate firmware behavior with current spikes.
• Automate long-duration tests and log temperature — leakage and regulator efficiency vary strongly with temperature.
• Look for small periodic spikes; they often indicate an unexpected timer or peripheral still running (SysTick, watchdog tick, logging).

Practical checklist: low-power bring-up and verification protocol

This is the working protocol I use on new battery-powered MCUs. Execute and tick off each item.

1. Hardware sanity (before firmware)

   • Confirm battery chemistry, expected voltage window, external regulator type, and quiescent currents.
   • Verify VBAT routing and that backup domain is powered if RTC/backup needed.

2. Datasheet drilling

   • Extract: sleep-mode currents, wake sources per mode, retention RAM, regulator options, oscillator behaviours and startup times, watchdog behaviour across sleep. Record these in a single "power parameters" sheet.

3. Minimal firmware baseline

   • Boot to main loop that disables all peripherals and enters the deepest sleep mode that still allows UART/console if you need debug. Measure baseline sleep current.
   • If baseline > datasheet by >20%, stop and debug hardware (solder bridges, miswired VBAT, LED current).

4. Active-path optimization

   • Implement a minimal active cycle: wake, read sensors, buffer, transmit, go sleep.
   • Measure single-cycle energy and iterate: reduce clock speed, gate peripherals, reduce sensor power by powering it from a load switch.

5. Wake-path hardening

   • Exercise every wake source (RTC, EXTI pins, radio) and measure false wake rates.
   • Add input conditioning (pulls, RC filters, comparator thresholds) for noisy wake lines.

6. State retention and recovery test

   • Simulate power-domain transitions and brownouts. Ensure backup registers restore expected values.

7. Stress and soak

   • Run continuous cycles over days at target temperature and collect statistics on average current, spike distribution, and wake-failure cases.

8. Document and lock

   • Capture the final energy per task, sleep current, I_avg, expected battery life, and measurement method (instrument, sampling frequency).

Important: treat measurement as part of verification; unverified power claims are product risks.

Sources
Dynamic Power Consumption - ScienceDirect - Explanation and formula P = α·C·V²·f (dynamic power), and discussion of dynamic vs static power.

ARM Cortex‑M3 Technical Reference Manual (DDI0337) - Discussion of SLEEP/SLEEPDEEP, clock-gating and related low-power mechanisms on Cortex-M cores.

STM32U031F8 product page — STMicroelectronics - Representative ultra‑low‑power MCU product page with VBAT, standby/stop/ run-mode consumption and features used as examples.

AN4991 — STM32 low‑power modes (USART/LPUART wakeup) — STMicroelectronics - Guidance on RTC/LSE usage, wakeup sequences and low-power mode behaviour for STM32 families.

SAM L21 / SleepWalking and power domain docs — Microchip and developer SleepWalking pages (Microchip) - Description of SleepWalking, dynamic power domain gating, and retention options for the SAM L family.

Getting Started with Qoitech Otii Arc (power-measurement example) — CNX Software - Practical walk-through of using Otii Arc for energy measurements, capturing traces and computing energy-per-task.

STM32 low-power practices (community & app-note pointers) — ST Community/STM32CubeMX docs - Practical tips and links to ST application notes and Cube tools for power calculation and mode examples.

STM32 power debugging primer — Compile N Run - Practical debugging checklist and simple code examples for toggling debug pins to correlate current traces to firmware behavior.

Apply the procedure: map domains, gate clocks and peripherals aggressively, pick the deepest sleep mode that supports the wake sources you need, implement deterministic suspend/resume sequencing with minimal retained state, and measure energy per operation until the battery-life number stabilizes and survives temperature and factory variation.