Why sleep current beats the datasheet

The datasheet promises a few microamps in deep sleep. The board on your bench draws hundreds. A device meant to run for years on a coin cell would last weeks, and the firmware looks correct.

The chip is rarely lying. The datasheet figure describes the chip alone, in a named mode, with every pin in a known state and nothing else connected. Your product adds a regulator, sensors, a flash, a battery monitor, a programming header and dozens of pins, and each one can add current. Finding those microamps is a method, not a guess. It starts with knowing exactly what you are comparing against.

Read what the datasheet number means

Check three things before you compare anything.

First, the mode. Vendors use names that do not line up. STM32 Stop and Standby, nRF52 System ON idle and System OFF, and ESP32 light sleep and deep sleep are different states that keep different things alive. A figure for “deep sleep” may include or exclude the real-time clock and RAM retention, and your firmware may be using a lighter mode than the one on the front page.

Second, the conditions: supply voltage, temperature, which wake sources are enabled, and whether the number is typical or maximum. Leakage rises with temperature, so a reading at room temperature flatters a device that will live in a warm enclosure.

Third, where the number is measured. It is at the chip’s supply pins. It does not include anything you put around the chip.

Rule out the debug probe first

The most common cause of a wrong reading is the tool that loaded the firmware.

On STM32 parts, the debug configuration register (DBGMCU_CR) holds bits such as DBG_STOP and DBG_STANDBY. They keep clocks running in low-power modes so a debugger can stay attached. The register is cleared by a power-on reset, not by a system reset. Reset the chip after a debug session and the bits can still be set. The chip sleeps, but not all the way, and the current sits above the datasheet figure until power is removed.

On nRF52 parts, a debug session or a programming step can leave the chip in debug interface mode. That keeps part of the chip running and adds current until power is cycled. While a debugger is attached, System OFF is emulated rather than real. Nordic’s own forum answers give the same advice: cycle power, then measure.

ESP32 development kits have a different problem. The kit carries a linear regulator, a USB-to-serial bridge and a power LED, and together they can draw milliamps no matter what the chip does. A dev-kit reading says nothing about the chip’s sleep current. Measure at the module’s supply pin, or on your own board.

The rule is simple: measure a release build, with the probe disconnected, after a full power cycle. The same rule applies on a production line. A unit that is programmed and checked without a power cycle can read high for reasons that will not exist in the field. Decide where in the test procedure the sleep-current reading happens, and make sure power has been cycled before it.

The usual suspects

Once the probe is out of the picture, the excess current is almost always on the board or in the pin configuration.

Leak	How it happens	What to check
Pins	Floating inputs, or pins driven against a pull	Every pin’s state in sleep, in schematic and firmware
Pull-ups	A resistor to the rail on a line held low	Resistor value and the line’s sleep level
Regulator	The regulator’s own quiescent current	Its curve at your actual light load
Peripherals	Sensors, radios and level shifters that power up running	Register defaults and each part’s shutdown mode
Flash	External SPI flash left in standby	Its deep power-down command, and whether firmware sends it

Pins. A floating CMOS input can sit near mid-rail, where both transistors in its input stage conduct. ST’s low-power guidance for STM32 is to put unused pins in analog mode, which switches off the input Schmitt trigger and any pull resistor. On ESP32, internal pull-ups and pull-downs are enabled by default. If an external circuit drives the pin during deep sleep, current flows through them. Espressif’s documentation tells you to isolate the pin with rtc_gpio_isolate() before sleeping. Only RTC-capable pins can be held or isolated through deep sleep, so check the pin table before you assign functions to pins.

Pull-ups. A 10 kΩ pull-up on a button that is held low costs 330 µA at 3.3 V. That is just V divided by R, and any resistive path across the rail costs it continuously. A pair of 1 MΩ resistors forming a battery-voltage divider across 3.6 V costs 1.8 µA, which can be as large as the whole sleep budget. Sample the battery through a switch instead of leaving the divider connected, and pick pull-up values for the sleep state, not only for edge speed.

Regulators. A regulator’s quiescent current is a fixed cost you pay all day. A linear regulator chosen for dropout or noise can draw more just sitting there than the microcontroller draws asleep. Read the quiescent-current curve at your real load and temperature, not the headline number. On a design that sleeps most of the time, the regulator is a first-order decision.

Peripherals. Many sensors power up in a continuous-conversion mode. Read the register defaults, then put each part into its own shutdown or one-shot mode before the microcontroller sleeps. Watch for back-powering as well: a powered peripheral driving a pin on an unpowered chip can feed that chip through its protection diodes, and the readings stop making sense.

Flash. In ESP-IDF, deep sleep powers down the SPI flash regardless of configuration, while light sleep leaves it powered by default. Espressif recommends the flash’s deep power-down mode over cutting its supply in light sleep. The same logic applies to any external NOR flash: standby current is usually many times its deep power-down current, and the part stays in standby until firmware tells it otherwise — worth checking early if you’re already qualifying a second-sourced flash for the board.

Find it on the bench

Work in this order.

1. Measure at the battery, with the right instrument. A bench multimeter on a microamp range puts a series shunt in the supply, and the voltage it drops can brown out the target when the chip wakes. It also changes range mid-burst. A current profiler, or a small shunt read by a scope or a logging amplifier, does not have this problem.
2. Read the trace, not the average. Wake bursts hide inside averages. A device that wakes once a second and draws 10 mA for 10 ms averages 100 µA from the burst alone, far above a sleep floor of a few microamps. Periodic spikes are wake-ups: the RTC, a watchdog, a radio interval or a sensor interrupt. A flat, elevated floor is a static leak. Different shapes have different causes.
3. Mark the trace. In a debug build, toggle a spare pin at each firmware state so you can line up code with current. Remove the marker before the final measurement, because the pin itself costs current.
4. Bisect the hardware. Lift the regulator output, remove the sensor, or cut a jumper to an entire rail, and watch the floor drop. This only works if the board lets you do it.
5. Measure hot. Repeat at the temperature the product will actually see. A leak that is invisible at room temperature can dominate at the top of the range.

Leave room to find it next time

A few layout choices make the next round of debugging far cheaper.

• A shunt footprint in the battery path. A zero-ohm link you can replace with a measurement shunt, or a clean place to insert a meter.
• Switched rails for sensors and flash. A load switch turns a stubborn leak into a line of firmware.
• Test points and jumpers on each rail. These are what make bisection possible without rework.
• Battery-monitor dividers that can be switched off.
• A sleep-current check in production test. It catches the unit with a stuffing error or a stray solder bridge, and it is where the “programmed but not power-cycled” reading shows up. It belongs in the fixture design, not as an afterthought.

Sleep current is a board problem and a firmware problem at once, which is why it stays unsolved when the two are debugged separately. We work on both sides. Send us the schematic, a firmware build, a current trace of the sleep state, and the battery and battery life you need.