Power profiling and measurement

Quick Cap

Power profiling is the practice of measuring, recording, and analyzing a device's current consumption over time so you can find and fix energy waste. Unlike desktop software where performance is measured in milliseconds, embedded power optimization is measured in microamps and microwatt-hours, and the difference between good and bad can mean years of battery life. Interviewers test whether you know the measurement tools, understand their limitations, and can systematically track down unexpected power drains.

Key Facts:

• Shunt resistor + oscilloscope is the simplest measurement method but struggles with dynamic ranges spanning uA to hundreds of mA
• Dedicated power analyzers (Nordic PPK2, Joulescope, Qoitech Otii) auto-range across uA-to-A and correlate current with GPIO triggers
• On-board current sense ICs (INA219, INA226) enable in-circuit monitoring without external equipment
• Sleep current is the dominant contributor to battery life in duty-cycled IoT devices -- even 10 uA of leakage at 1% duty cycle dwarfs the active-mode contribution
• Debug probes keep MCUs awake -- SWD pull-ups on SWDIO/SWCLK can prevent deep sleep, adding milliamps of phantom current
• Profiling methodology: establish baseline, profile each firmware state, correlate with code, optimize, validate

Deep Dive

At a Glance

Measurement Techniques in Detail

Shunt resistor method: Insert a small resistor (1-100 Ohm) in series with the power supply and measure the voltage drop across it. Current = V_drop / R_shunt. This is cheap and fast, but choosing the right shunt value requires balancing sensitivity against voltage drop: a 10 Ohm shunt gives a nice 10 mV/mA signal, but drops 1 V at 100 mA -- potentially browning out the MCU. A 0.1 Ohm shunt has negligible drop but only 0.1 mV/mA, requiring a sensitive amplifier.

On-board current sense ICs: The INA219 and INA226 combine a precision shunt amplifier with an I2C ADC. They sit permanently in the power path and let firmware read its own current consumption -- useful for field diagnostics, battery fuel gauging, and automated power testing. The INA226 offers 16-bit resolution and is accurate to within 0.1% of full scale.

Dedicated power analyzers: These tools auto-range across 6+ decades of current (nA to A), eliminating the shunt-value dilemma. They integrate energy over time, export current waveforms synchronized to GPIO markers, and often include software that overlays the current trace on a timeline of firmware events.

Power Analyzer Comparison

Measuring Sleep vs Active Current

For duty-cycled devices, average current is approximated by:

I_avg = (I_active x t_active + I_sleep x t_sleep) / (t_active + t_sleep)

At a 1% duty cycle (10 ms active every 1 s), if I_active = 10 mA and I_sleep = 2 uA:

I_avg = (10 mA x 0.01 s + 0.002 mA x 0.99 s) / 1 s = 0.102 mA = 102 uA

This shows why sleep current dominates: even a modest increase from 2 uA to 20 uA raises average current by 18% (102 uA to 120 uA), directly reducing battery life.

Common sources of unexpected sleep current:

• Debug probe connected (SWD pull-ups keeping core powered)
• Internal pull-ups enabled on unused GPIO pins
• Floating GPIO inputs drawing shoot-through current
• Peripheral clocks left enabled (ADC, timer, UART)
• External pull-ups to VCC on bus lines (I2C) when bus is unused
• Voltage regulator quiescent current (LDO vs switching)

Profiling Methodology

[1. Baseline]      [2. State Map]      [3. Correlate]      [4. Optimize]      [5. Validate]
       |                   |                   |                    |                   |
  Measure total        Identify each       Toggle GPIO at       Target highest      Re-measure
  average current      firmware state      state transitions,   power states,       after changes,
  with default FW      (init, active,      overlay on current   apply fixes         compare to
                       sleep, TX, RX)      waveform             (clock gating,      baseline
                                                                sleep modes,
                                                                peripheral off)

1. Baseline -- Flash the default firmware and measure average current over a full duty cycle. Record this as the reference point.
2. State map -- Identify every distinct firmware state (initialization, sensor read, radio TX, radio RX, idle, sleep). Understand the expected duration and current for each.
3. Correlate -- Add GPIO toggles at state transitions. Use the power analyzer's GPIO trigger feature to align the current waveform with firmware phases. This reveals which state consumes more than expected.
4. Optimize -- Disable unused peripherals, switch to lower-power clock sources, use deeper sleep modes, reduce TX power, shorten active windows.
5. Validate -- Re-measure average current and per-state current after each change. Confirm that the optimization did not break functionality (radio still connects, sensor data is accurate).

Software-Based Power Estimation

When hardware measurement is impractical (early design phase, CI environment), software estimation provides a rough power budget:

/* Simple energy estimator using datasheet current values */
typedef struct {
    float active_current_mA;
    float sleep_current_uA;
    float tx_current_mA;
    uint32_t active_time_ms;
    uint32_t sleep_time_ms;
    uint32_t tx_time_ms;
} power_profile_t;

float estimate_battery_life_hours(power_profile_t *p,
                                   float battery_mAh) {
    float cycle_ms = p->active_time_ms + p->sleep_time_ms
                   + p->tx_time_ms;
    float avg_mA   = (p->active_current_mA * p->active_time_ms
                   +  (p->sleep_current_uA / 1000.0f) * p->sleep_time_ms
                   +  p->tx_current_mA * p->tx_time_ms)
                   / cycle_ms;
    return battery_mAh / avg_mA;
}

This is useful for early trade-off analysis ("can we afford a 3-second radio window?") but must be validated with real measurements because datasheet values are typical, not worst-case, and do not account for PCB leakage, regulator efficiency, or external component quiescent currents.

Debugging Story: 10x Expected Sleep Current

A BLE sensor tag was specified to run for 2 years on a CR2032 coin cell (225 mAh). Lab measurements showed 30 uA average current instead of the expected 3 uA, cutting battery life to roughly 10 months.

The team connected a Nordic PPK2 in source mode and captured the current waveform over several BLE advertising cycles. The waveform showed the expected 8 mA peaks during radio TX, but the baseline between TX events was 25 uA instead of the datasheet-specified 1.5 uA for System ON / RAM retention.

Step 1: Disconnect the J-Link debug probe. Sleep current dropped from 25 uA to 12 uA -- the SWD pull-ups on SWDIO and SWCLK were sourcing current through the MCU's I/O protection diodes even in deep sleep.

Step 2: With the probe disconnected, add a GPIO toggle before and after sd_app_evt_wait() to correlate the current trace with firmware state. The 12 uA baseline was flat with no periodic spikes, ruling out unexpected wake-ups.

Step 3: Systematically disable unused peripherals. Disabling the UART peripheral (which had been left initialized for debug logging) dropped current to 5 uA. Configuring three floating GPIO pins as inputs with pull-downs dropped it to 2.8 uA.

Step 4: Final validation showed 2.8 uA average, yielding a calculated battery life of 2.3 years -- exceeding the 2-year target with margin.

The lesson: always disconnect the debug probe for power measurements, and methodically disable peripherals one at a time to isolate the source of excess current.

Interview Focus

Classic Interview Questions

Q1: "How do you measure the current consumption of an MCU that switches between 2 uA sleep and 50 mA active?"

Model Answer Starter: "A regular multimeter or a fixed shunt resistor cannot handle that 4+ decade dynamic range well. I would use a dedicated power analyzer like a Joulescope or Nordic PPK2 that auto-ranges across nA to amps. These tools capture the full waveform, letting me see both the sleep baseline and the active-mode peaks. I place a GPIO toggle at the sleep/wake boundary so the tool correlates the current trace with firmware state. If I only have an oscilloscope, I use two shunt values and two measurements -- a high-value shunt for the sleep phase and a low-value shunt for the active phase."

Q2: "A battery-powered device drains its battery in half the expected time. Walk me through your debugging approach."

Model Answer Starter: "First I measure average current with a power analyzer over a full duty cycle and compare to the design budget. If it is higher than expected, I use GPIO triggers to identify which firmware state consumes more than its allocation. Common culprits: debug probe connected (SWD pull-ups), floating GPIO pins, unused peripherals left clocked, or the device waking up more frequently than intended. I disable peripherals one at a time and re-measure after each change to isolate the excess. I also check that the expected sleep mode is actually being entered by verifying the current drops to the datasheet value for that mode."

Q3: "What is the difference between an INA219 and a Joulescope for power measurement?"

Model Answer Starter: "An INA219 is an on-board I2C current sense IC that sits in the power path permanently. It is cheap, small, and great for in-field monitoring or automated test fixtures, but it is limited to about 1 kHz sample rate and 10 uA minimum resolution. A Joulescope is a standalone precision instrument with 2 MHz sample rate and nA-level sensitivity -- ideal for detailed profiling during development but not a permanent fixture on the board. I use INA219/226 for production monitoring and fuel gauging, and Joulescope or PPK2 for development profiling."

Q4: "How does a debug probe affect power measurements, and how do you work around it?"

Model Answer Starter: "A connected debug probe sources current through its SWD pull-ups into the MCU's SWDIO and SWCLK pins. This can add 1-5 mA and prevent the MCU from entering deep sleep, because the debug access port stays powered. The workaround is to disconnect the probe entirely during power measurements. Some probes offer a pass-through or measurement mode that tri-states the debug pins. Alternatively, I program the firmware to toggle a GPIO at key states and use the power analyzer's digital input channels to correlate current with firmware phase, eliminating the need for a live debug connection."

Q5: "How would you estimate battery life for a device that has not been built yet?"

Model Answer Starter: "I build a spreadsheet power budget using datasheet current values for each operating state -- active with CPU running, active with radio TX, radio RX, idle, and sleep. I estimate the duration of each state per duty cycle from the firmware design. Average current is the weighted sum of (I_state times t_state) divided by the total cycle time. I add margins for regulator efficiency (typically 85-90% for a switching regulator), PCB leakage, and component quiescent currents. This gives a rough estimate. Once hardware is available, I validate with a power analyzer and adjust the budget based on actual measurements."

Trap Alerts

• Don't say: "I just use a multimeter to check current" -- multimeters average over time, hiding transient spikes and failing to capture dynamic range
• Don't forget: Disconnect the debug probe before measuring sleep current -- this is one of the most common measurement errors
• Don't ignore: The difference between typical and worst-case datasheet current values -- designs should budget for worst-case

Follow-up Questions

• "How do you measure power consumption of a device with multiple supply rails?"
• "What techniques do you use to reduce regulator quiescent current for always-on IoT devices?"
• "How would you profile power consumption in an RTOS-based system with multiple tasks?"
• "Describe how you would set up automated power regression testing in CI."

Practice

Real-World Tie-In

Agricultural Sensor Network -- A solar-powered soil moisture sensor needed to survive 7 consecutive cloudy days on a 500 mAh LiPo. Initial profiling with a Joulescope showed 850 uA average instead of the 200 uA budget. GPIO-correlated capture revealed that the LoRa radio's SPI bus was being polled every 100 ms instead of using the DIO interrupt pin. Switching to interrupt-driven receive and adding a 10-second aggregation window before TX reduced average current to 180 uA, providing a 10-day battery margin.

Wearable ECG Patch -- A medical patch running on a tiny 40 mAh zinc-air battery targeted a 24-hour runtime. Initial measurements showed 3.2 mA average (only 12.5 hours). Power state mapping revealed that the 24-bit ADC was running continuously at 500 SPS when the clinical requirement was only 250 SPS with intermittent recording. Halving the sample rate and duty-cycling the ADC (2 seconds on, 3 seconds off) dropped average current to 1.4 mA, yielding 28+ hours of runtime. The INA226 on the board provided runtime current telemetry that the companion phone app used to display remaining battery percentage to the clinician.