Getting the Most Battery Life Out of the nRF54L15

Optimizing battery life and power consumption on Nordic's nRF54L15 microcontroller

You flash a bare peripheral_hr sample onto your nRF54L15 DK, hook up a PPK2, and read 350 µA idle. The datasheet says 1.8 µA for System ON Sleep. That’s a 175x gap, and the cause is mundane: Nordic’s defaults leave almost everything turned on, including UART logging, full RAM retention, the LDO regulator, and a bunch of floating GPIOs quietly sinking current. Getting from 350 µA to sub-2 µA takes about 7 deliberate firmware changes, each one measurable and worth knowing before you commit this SoC to a coin cell design.

All measurements below were taken on an nRF54L15 DK running NCS 2.7.x via Nordic PPK2, averaged over 60-second windows. If you’re evaluating the nRF54L15 for a battery-powered project (or comparing it against your trusty nRF52832), the numbers here should get you to a realistic power budget on day one.

What Changed from the nRF52 Power Architecture

If you’re coming from nRF52-series parts, don’t assume the power states map 1:1. The nRF54L15 introduces multiple independent power domains (core and peripheral), new LFOSC source options, and finer-grained RAM retention banking. It does not have a separate network core like the nRF5340, which simplifies things considerably.

| State               | nRF52832 Equiv.  | nRF54L15 Name     | Typical Current  |
|---------------------|------------------|---------------------|-----------------|
| CPU active (64MHz)  | CPU Run          | Active              | ~3.5 mA         |
| Idle, RAM retained  | System ON Idle   | System ON Idle      | ~30 µA          |
| Deep sleep, RTC on  | System ON Sleep  | System ON Sleep     | ~1.8 µA         |
| Full off, GPIO wake | System OFF       | System OFF          | ~0.3 µA         |

Measured on nRF54L15 DK, NCS 2.7.x. Your numbers will vary by configuration.

“System ON Idle” keeps the CPU clock gated but peripherals and all RAM domains powered. “System ON Sleep” powers down the core domain and most peripherals, retaining only selected RAM banks and the LFOSC for RTC wake. In Zephyr’s pm_state, PM_STATE_SUSPEND_TO_IDLE maps to System ON Idle; PM_STATE_SUSPEND_TO_RAM maps to System ON Sleep. Getting into the deeper state requires you to actively strip back what’s retained.

The Default NCS Project: Where Your Power Goes

A stock hello_world build with default board configs idles around 300-350 µA. That’s before you’ve written a single line of application code.

The usual suspects: UART console output pulling in the HFXO, RTT debug segments staying active, serial recovery mode enabled, every RAM bank retained, and the LDO regulator doing all the voltage conversion (inefficiently). These are deliberate defaults that make development easier and power profiling worse. Your job is to peel them away for production.

Firmware Optimizations, Ordered by Impact

Each step below includes the configuration change and the measured current delta. Apply them cumulatively; the impact ladder at the end shows the full picture.

1. Disable Debug and Logging

The single biggest win. UART logging keeps the HFXO running and the serial peripheral powered.

# prj.conf
CONFIG_LOG=n
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_SERIAL=n
CONFIG_RTT_CONSOLE=n
CONFIG_USE_SEGGER_RTT=n

If your board overlay enables UART pins, disable them in your devicetree overlay:

&uart0 {
    status = "disabled";
};

Measured delta: ~350 µA → ~180 µA. Roughly half your idle current, gone.

2. Enable DCDC Regulators

The nRF54L15 has both a main DCDC converter and a radio DCDC. Out of the box on some NCS configurations, the LDO handles regulation, which wastes energy as heat.

# prj.conf
CONFIG_SOC_DCDC_NRF54L_MAIN=y
CONFIG_SOC_DCDC_NRF54L_RADIO=y

Confirm in your devicetree that the DCDC nodes aren’t overridden to disabled. The radio DCDC matters most during TX bursts, but the main DCDC pulls its weight at idle too.

Measured delta: ~180 µA → ~120 µA.

3. Minimize RAM Retention

This is where the nRF54L15 diverges sharply from nRF52. RAM is banked into multiple sections (the exact layout depends on your linker configuration, but think 32-64KB granularity). Each retained bank costs roughly 0.3-0.5 µA in System ON Sleep. If your application only needs 32KB of retained state, powering all 256KB is wasteful.

In your devicetree overlay, configure which RAM sections stay retained during sleep. The Zephyr PM subsystem respects these settings when entering PM_STATE_SUSPEND_TO_RAM. You’ll need to ensure your stack, heap, and any persistent buffers land in the retained sections via linker script adjustments.

Measured delta: ~120 µA → ~80 µA (powering down 3 of 4 banks).

4. Select the Right LFOSC Source

The nRF54L15 gives you 3 options for the low-frequency clock: the internal RC oscillator (~1 µA, ±250ppm), an external 32.768kHz crystal (~0.5 µA, ±20ppm), or a synthesized clock from the HFXO (accurate but power-hungry).

For BLE, you almost certainly want the LFXO. The RC oscillator’s drift forces more frequent clock calibration, which wakes the HFXO periodically and eats into your power budget. For non-BLE periodic wake applications where ±250ppm is acceptable, the RC saves you a crystal and a few board-level components.

# prj.conf (for LFXO)
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=n

Measured delta: ~80 µA → ~55 µA (switching from RC with calibration to LFXO on a BLE advertising profile).

5. Clean Up GPIO State

On nRF52 parts, nrf_gpio_cfg_default() left pins in a reasonably low-power disconnected state. On the nRF54L15, the default pin configuration can leave internal pull-ups or pull-downs engaged, and floating inputs on connected-but-unused pins sink measurable current. Explicitly disconnect every pin your application doesn’t use:

nrf_gpio_cfg(pin,
    NRF_GPIO_PIN_DIR_INPUT,
    NRF_GPIO_PIN_INPUT_DISCONNECT,
    NRF_GPIO_PIN_NOPULL,
    NRF_GPIO_PIN_S0S1,
    NRF_GPIO_PIN_NOSENSE);

Do this in your board overlay or early in main(). Pay special attention to pins routed to DK peripherals (LEDs, buttons, debug headers) that you aren’t using in production.

Measured delta: ~55 µA → ~48 µA. Modest, but it adds up when you’re chasing the last microamps.

6. Gate Unused Peripheral Power Domains

The nRF54L15 has independent power gating for several peripheral blocks: SPI, I2C, ADC, PWM, and others. Zephyr’s pm_device framework handles this if drivers are properly configured, but some peripherals don’t fully power down unless you explicitly tell them to.

Check that unused peripherals are status = "disabled" in devicetree. For peripherals you use intermittently (an SPI sensor you read once per minute, for example), suspend after each transaction and resume before the next:

pm_device_action_run(dev, PM_DEVICE_ACTION_SUSPEND);

// ... later, before next read:
pm_device_action_run(dev, PM_DEVICE_ACTION_RESUME);

Measured delta: ~48 µA → ~40 µA. Varies widely depending on which peripherals are in your design.

7. BLE-Specific: Connection Interval and TX Power

On the nRF54L15 at 0 dBm TX power with DCDC enabled, a single BLE connection event costs roughly 15-20 µA averaged over time at a 1-second connection interval. Drop to a 30ms interval and that climbs to ~300 µA average, because you’re waking the radio 33x more often.

If your application can tolerate it, push connection intervals as high as your latency requirements allow. For sensor applications reporting every 10-30 seconds, a 1-2 second connection interval is usually fine.

The cumulative impact of all 7 optimizations:

Baseline (debug on, LDO, all RAM)   ████████████████████████████  ~350 µA
+ Disable debug/UART                ██████████████████████        ~180 µA
+ Enable DCDC                       █████████████████             ~120 µA
+ Minimize RAM retention            ██████████████                ~80 µA
+ LFXO configured                   ████████████                  ~55 µA
+ GPIO cleanup                      ███████████                   ~48 µA
+ Peripheral gating                 ██████████                    ~40 µA

Three Profiles on a CR2032

All measured on nRF54L15 DK with DK peripherals disabled, PPK2 on the dedicated current measurement header. CR2032 capacity assumed at 225 mAh (derated from the nominal 235 mAh for pulse loads).

| Profile                          | Avg Current | CR2032 Life  | Key Settings                     |
|----------------------------------|-------------|--------------|----------------------------------|
| A: BLE Beacon (1s adv interval)  | ~42 µA      | ~7 months    | 0dBm TX, DCDC, LFXO, min RAM    |
| B: BLE Connected Sensor          | ~58 µA      | ~5 months    | 1s CI, sensor read/10s, DCDC     |
| C: Deep Sleep + Periodic Wake    | ~2.1 µA     | ~12 years    | System ON Sleep, 1 bank, 60s wake|

Profile C is the headline number. If your device mostly sleeps and wakes briefly to read an SPI sensor and queue data, you’re looking at multi-year CR2032 life. The waking burst (CPU active + SPI transaction) is ~3.5 mA for a few milliseconds; amortized over 60 seconds, it barely registers.

For devices that need to stream data back via Bluetooth while also reaching beyond local range, you might consider pairing BLE with satellite connectivity. The Hubble Device SDK provides a firmware integration for BLE devices that could complement these low-power profiles, especially for asset tracking or remote monitoring where terrestrial connectivity isn’t available.

nRF54L15 vs. nRF52832 vs. nRF52840

| Metric               | nRF52832  | nRF52840  | nRF54L15  |
|----------------------|-----------|-----------|-----------|
| Sleep (RTC, min RAM) | ~1.9 µA   | ~1.5 µA   | ~1.8 µA   |
| BLE TX (0dBm)        | ~5.3 mA   | ~4.8 mA   | ~4.2 mA   |
| CPU active (64MHz)   | ~3.7 mA   | ~3.2 mA   | ~3.5 mA   |
| System OFF           | ~0.3 µA   | ~0.4 µA   | ~0.3 µA   |
| Flash                | 512KB     | 1MB       | 1.5MB     |
| RISCV crypto accel.  | No        | CryptoCell| Yes       |

The sleep currents are roughly comparable. The nRF54L15 pulls ahead in efficiency per operation: more flash, RISC-V crypto acceleration, and lower TX current mean it finishes work faster and returns to sleep sooner. If you’re doing periodic crypto operations (secure sensor payloads, DFU signature verification), that difference compounds.

When does the nRF52832 still win? Cost-sensitive, high-volume designs where the BOM difference matters and you don’t need the extra flash or crypto. The ecosystem is also more mature, with more community examples and fewer SDK rough edges.

Gotchas That’ll Waste Your Afternoon

The DK lies (a little). The nRF54L15 DK has onboard LEDs, a debug IC, and voltage dividers that all draw current. Use the dedicated current measurement jumper and disconnect the debugger after flashing. Otherwise you’re measuring the board, not the SoC.

CONFIG_PM isn’t always on. In some NCS 2.7.x sample configs, power management is disabled by default. If your device never enters System ON Sleep despite your code requesting it, check that CONFIG_PM=y is set.

Watchdog keeps domains awake. If you’ve enabled the watchdog timer, it prevents certain peripheral power domains from shutting down. You’ll see 5-10 µA extra that vanishes when you disable it. In production, feed the watchdog from your RTC wake callback so it doesn’t block sleep entry.

EasyDMA peripherals retain power. SPIM, UARTE, and other DMA-capable peripherals can hold their power domain active if a transaction was started but not properly completed. Always call nrfx_*_uninit() or use Zephyr’s pm_device suspend before entering sleep.

Building Your Power Budget

The nRF54L15 can hit its datasheet numbers, but you have to earn them. Start with the optimization ladder above, measure after each step, and build your power budget from actual measurements rather than the product specification’s “typical” column.

If you’re integrating BLE-based devices into a larger IoT deployment with cloud-side data handling, the Hubble cloud integration guide covers webhook and API patterns for getting device packets into your backend with minimal overhead.

For your next step: grab a PPK2, flash a minimal application onto your DK, and start at step 1. Measure everything.

Hubble Network connects your ultra-low-power BLE devices directly from satellite, eliminating gateway infrastructure entirely. Learn more →