You cannot simulate MCU power consumption. You can only measure it.

Someone always asks whether the simulator can tell them the battery life.

No.

Every tool I trust for MCU power consumption sits on a wire between a supply and a chip. Joulescope. Qoitech Otii. Nordic's Power Profiler Kit II. Espressif's own current-measurement guide names two of those and then tells you to cut the module's supply and put an ammeter in the gap.¹²³⁴

Skip the probe and you are not measuring power.

What the real tools are

Joulescope is a shunt and a voltmeter that samples at 2 MHz so a sleep-to-radio spike does not disappear between ranges.² Otii Arc and Ace are a source-measure unit: they power the device and record current, voltage, power, and energy at the same time.³ The PPK2 is the same idea at Nordic-kit money, ampere-meter or source, 200 nA to 1 A, with digital inputs so you can mark which code was running when the spike happened.⁴

All three assume a device under test. A board. A module. A pair of banana plugs. The firmware is running on silicon. The number on the screen is charge that left a physical rail.

Espressif's module guide barely pretends otherwise. Do not measure a dev board, the rest of the board still draws. Cut the module supply. Use an ammeter that can track deep-sleep nanoamps and active milliamps without dropping the rail. They recommend Joulescope and the PPK2, then publish a waveform: 8.14 µA asleep, about 23.88 mA active, on a specific module, with a specific example.¹

That is a measurement. It has a setup photo and a shunt in the picture.

The things that look like simulation, and are not

Datasheet tables. "Typical 5 µA in stop mode." Those are vendor lab numbers on a reference setup. Useful as a floor. They are not your firmware, your regulators, or your leaky GPIO.

Nordic's Online Power Profiler estimates BLE, LTE-M, and NB-IoT current from lab-tested protocol profiles.⁴ It is a calculator over someone else's traces. It will not see the extra milliamp your debug pin is sourcing.

Instruction-level energy models exist in papers. They assign a cost to an opcode or a memory access on one core, usually under one voltage and one temperature. They are research. I have not seen a firmware team ship a battery claim off one.

QEMU, Renode, Ozone-Sim, native_sim — none of them model the analog current out of the pad. They model enough of the digital machine to run code. Current is not a register. It is charge on a rail those models do not have.

I wrote a longer field guide to what simulation can't catch. Power is the cleanest entry on that list, because the simulator does not even try. The failure mode is not a quiet zero from a missing DWT. The failure mode is you asking a digital model for a current it does not have.

Cycle-accurate digital simulation does not rescue this. Cycle-accurate means instruction timing, not joules. A perfect cycle count still needs a current-per-cycle map that matches your silicon, your voltage, your temperature, and every analog block the radio just powered. Nobody hands you that map for a modern wireless MCU and stands behind it.

Why the honest "no" is useful

Firmware CI can, and should, run a lot of checks without a board. I have a whole post on what belongs in simulation versus HIL. Power is HIL. Not because HIL is morally better. Because the quantity you want is electrical, and the simulator does not have the circuit.

An agent optimizing sleep current without a meter will optimize the story. It will delete a log line, flip a clock bit, and declare victory. The rail does not care.

If you want the loop to close, the agent needs the same thing a human needs: a trace from a probe, time-aligned with a GPIO mark or a log, on the firmware you actually intend to ship. That is slower than a unit test. It is also the only number that counts.

You cannot simulate MCU power consumption in any sense a battery engineer would accept. You measure it.

Sources

Footnotes

1. Espressif, "Current Consumption Measurement of Modules," ESP-IDF Programming Guide v6.0.2, accessed 2026-08-14. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-guides/current-consumption-measurement-modules.html ↩ ↩²

2. Jetperch, "Joulescope JS220 User's Guide," v1.9, accessed 2026-08-14. https://download.joulescope.com/products/JS220/JS220-K000/users_guide/Joulescope%20JS220%20User%27s%20Guide%20v1_9.pdf ↩ ↩²

3. Qoitech, "Power and current profiling," Otii documentation, accessed 2026-08-14. https://docs.qoitech.com/en/use-cases/power-and-current-profiling ↩ ↩²

4. Nordic Semiconductor, "Power Profiler Kit II," product page, accessed 2026-08-14. https://www.nordicsemi.com/Products/Development-hardware/Power-Profiler-Kit-2 ↩ ↩² ↩³