How Do You Minimise Current Draw on an nRF52 in BLE Applications?

Detailed Explanation

The nRF52 series is the dominant choice for coin-cell and energy-harvesting BLE products precisely because it offers extremely low sleep currents. But those datasheet numbers require deliberate firmware and hardware choices — the default configuration leaves significant power on the table. This page covers every major power reduction lever, in order of impact, for a typical BLE peripheral application.

---

1. Enable the DCDC Converter (Highest Impact)

Every nRF52 variant includes an internal DCDC step-down converter for the core supply (VDDCORE). It is disabled by default and runs in LDO mode unless you enable it explicitly. Enabling the DCDC converter is typically the single highest-impact power reduction in an nRF52 design.

Hardware requirement: An external inductor of typically 10 µH on the DCC and DCCDEC pins. This is a mandatory circuit element — without the inductor, enabling DCDC in firmware produces undefined behaviour. Refer to the reference circuit in your variant's product specification for the exact inductor footprint and decoupling capacitor placement.

In nRF Connect SDK with Zephyr: The DCDC is typically controlled via the nrf52840dk_nrf52840 board's device tree or directly via Kconfig. In recent NCS versions, CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=n and the DCDC setting is often controlled via the Power Management device:

CONFIG_BOARD_ENABLE_DCDC=y

In some NCS board definitions, this Kconfig is already set by the board file. Verify by checking zephyr/boards/<your-board>/<board>.conf in the workspace.

In nRF5 SDK (legacy): Set NRF_POWER->DCDCEN = 1 before entering the BLE stack, or call nrf_power_dcdcen_set(NRF_POWER, true) using the HAL.

The DCDC saving is most pronounced during active radio events (TX/RX), where the nRF52 core supply current reduction translates directly to longer battery life.

---

2. Maximise the BLE Advertising Interval

During advertising, the nRF52 radio wakes at each advertising event, transmits on three primary advertising channels (2402 MHz, 2426 MHz, 2480 MHz), and sleeps until the next event. The average current during the advertising phase is dominated by the energy per advertising event divided by the advertising interval.

The relationship is approximately linear: doubling the advertising interval approximately halves the average current from advertising.

Typical design approach:

• Not expecting connection soon: use a slow advertising interval — 1 second or longer. This is suitable for beacons, background presence advertising, and any scenario where a user must manually initiate a connection.
• Waiting for connection: use a shorter interval (100–200 ms) for a defined period (e.g. 30 seconds after button press), then fall back to a slow interval.

/* Slow advertising (1 s nominal interval) */
static const struct bt_le_adv_param slow_adv_param =
    BT_LE_ADV_PARAM_INIT(BT_LE_ADV_OPT_CONNECTABLE,
                         BT_GAP_ADV_SLOW_INT_MIN,   /* 1000 ms */
                         BT_GAP_ADV_SLOW_INT_MAX,   /* 1280 ms */
                         NULL);

/* Fast advertising (20–30 ms interval) for initial connection window */
static const struct bt_le_adv_param fast_adv_param =
    BT_LE_ADV_PARAM_INIT(BT_LE_ADV_OPT_CONNECTABLE,
                         BT_GAP_ADV_FAST_INT_MIN_1, /* 30 ms */
                         BT_GAP_ADV_FAST_INT_MAX_1, /* 60 ms */
                         NULL);

Per Nordic's application notes, measuring actual current with a PPK2 during advertising is the only reliable way to validate average current — datasheet numbers assume ideal conditions that may not reflect real PCB leakage and GPIO state.

---

3. Tune the BLE Connection Interval

Once a BLE connection is established, the radio wakes at every connection interval to exchange packets (even if no data needs to be transferred — an empty packet is sent to maintain the connection). The connection interval and the connection event length determine the radio duty cycle during a connection.

Connection interval — the time between connection events, typically configurable from 7.5 ms to 4 seconds per the Bluetooth specification. Longer intervals → fewer events per second → lower average current.

Request a longer connection interval from the peripheral side:

static const struct bt_le_conn_param power_conn_params =
    BT_LE_CONN_PARAM_INIT(
        BT_GAP_INIT_CONN_INT_MIN,  /* 80 units × 1.25 ms = 100 ms min */
        BT_GAP_INIT_CONN_INT_MAX,  /* 160 units × 1.25 ms = 200 ms max */
        0,                          /* slave latency (connection events to skip) */
        400);                       /* supervision timeout (400 × 10 ms = 4 s) */

/* Call after connection is established */
bt_conn_le_param_update(current_conn, &power_conn_params);

The central (smartphone or gateway) can accept or reject the requested interval. Most BLE central implementations accept intervals in the 100–500 ms range without issue; very long intervals (>1 second) may be rejected by some iOS or Android implementations — test with your actual central device.

Slave latency — allows the peripheral to skip up to N connection events if it has no data to send. This is the key mechanism for very low average current on sensors that send data infrequently. A slave latency of 9 with a 100 ms connection interval means the peripheral only wakes once per second even though the connection event occurs every 100 ms. Central-side data transfer latency increases proportionally.

---

4. Use System ON CPU Sleep (Zephyr Handles This)

Between BLE events, the CPU should be sleeping with all unnecessary peripherals off. In Zephyr NCS, this is handled automatically by the idle thread: when all application threads are blocked (waiting on semaphores, timers, or message queues), Zephyr's idle thread runs and calls the power management backend, which enters the lowest permitted power state based on the next scheduled wakeup.

Enable the Zephyr power management framework:

CONFIG_PM=y
CONFIG_PM_DEVICE=y

With CONFIG_PM=y, the idle thread on nRF52 enters System ON CPU sleep (equivalent to WFE in Cortex-M) when no threads are ready to run. The BLE subsystem and any active hardware timers continue to wake the CPU as needed. No explicit __WFE() calls are needed in application code.

---

5. Use System OFF for Deep Sleep

When no BLE connection is expected and no data needs to be processed, System OFF provides the lowest possible current. In Zephyr, trigger System OFF via:

#include <zephyr/pm/pm.h>

/* Request System OFF (equivalent to nRF52 SYSTEM_OFF power mode) */
pm_state_force(0, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});
k_sleep(K_FOREVER); /* Yield; pm subsystem takes over */

The device wakes from System OFF via a configured wakeup source (GPIO edge using GPIOTE channel, LPCOMP threshold crossing, or reset). On wake, the firmware restarts from the reset vector — System OFF wake is not a resume. Use the GPREGRET registers (2 bytes of retained register space) to communicate state between power cycles without relying on SRAM retention.

/* Before System OFF: save state in GPREGRET */
nrf_power_gpregret_set(NRF_POWER, MY_WAKEUP_STATE_FLAG);

/* After reset: read it back */
uint8_t reset_reason = nrf_power_gpregret_get(NRF_POWER);

SRAM retention in System OFF: The nRF52 can retain some or all SRAM regions during System OFF at the cost of higher sleep current. Retaining the full SRAM typically adds ~1 µA to the System OFF current per Nordic's product specifications. Only retain the SRAM regions your application actually reads after wake.

---

6. Disable Unused Peripherals

Active peripherals consume standby current even when idle. In Zephyr NCS, device power management allows peripherals to be suspended:

/* Example: suspend UART when not actively logging */
#include <zephyr/device.h>
#include <zephyr/pm/device.h>

const struct device *uart = DEVICE_DT_GET(DT_CHOSEN(zephyr_console));
pm_device_action_run(uart, PM_DEVICE_ACTION_SUSPEND);

/* Re-enable before transmitting */
pm_device_action_run(uart, PM_DEVICE_ACTION_RESUME);

Common peripheral sources of unexpected current:

• UART — enable pull-ups on RX/TX pins consume current if the other end is not driving. Disable or set UART pins to inputs during sleep.
• ADC (SAADC) — explicitly call nrf_saadc_disable() after each sample batch; the SAADC draws significant current if left enabled.
• GPIO pull resistors — a floating input with an internal pull-up or pull-down resistor draws current if the input is held at a voltage between the logic thresholds. Ensure every GPIO is either driven or configured correctly for the sleep state.

---

7. Check the Debug Interface

A connected J-Link or SWD debug probe can prevent the nRF52 from entering the lowest-power sleep states — some nRF52 variants hold the CPU active when a debugger is attached. For valid power measurements:

1. Disconnect the J-Link / SWD probe before measuring.
2. If you need logging during the measurement, use CONFIG_LOG_BACKEND_RTT=y and a standalone RTT Viewer (Ozone, J-Link RTT Viewer) rather than a full SWD debug session.
3. Measure with the final production firmware configuration — debug builds often enable watchdog refresh, logging backends, and extra tasks that increase idle current.

---

8. Measure with the Nordic PPK2

The Nordic Power Profiler Kit 2 (PPK2) is the essential tool for validating nRF52 power consumption. It measures current from 100 nA to 1 A at up to 1 million samples per second, generating a waveform that shows individual radio events, wakeups, and unexpected current spikes.

Ammeter mode (recommended for custom hardware):

1. Cut the power supply trace to the nRF52 VDD/VDDMAIN pin.
2. Route the supply through the PPK2's current sense input.
3. Use the nRF Connect for Desktop Power Profiler application to record and analyse the current waveform.

What to look for:

• Unexpected wakeup events — regular current spikes at unexpected intervals indicate a timer, peripheral, or BLE event waking the CPU more often than expected.
• Baseline current — the floor between events. If this is above the expected System ON sleep current (typically under 10 µA for a well-configured design), a peripheral or GPIO is leaking.
• Advertising/connection event shape — a correctly configured BLE device shows sharp narrow spikes at the advertising or connection interval, with a flat low baseline between them.

---

Power Reduction Priority Order

All figures in this table are typical values and order-of-magnitude estimates; measure with a PPK2 on your specific hardware to determine actual impact.

---

Design Considerations

• For a battery life worked example: see How to Calculate Battery Life for an Embedded Device, which provides the duty-cycle weighted average current formula. Apply that formula with the nRF52 current values you measure from the PPK2 waveform — not datasheet typical values, which may not reflect your firmware and hardware configuration.
• Compare nRF52 vs ESP32 power trade-offs: the nRF52 typically achieves sub-5 µA average current in BLE advertising mode with a 1-second interval; the ESP32 in modem sleep mode is typically in the 1–10 mA range. See ESP32 Deep Sleep and Power Management for the ESP32 approach.
• For the nRF52840 specifically: native USB (when enabled) adds a baseline current draw from the USB PHY. Disable the USB subsystem (CONFIG_USB_DEVICE_STACK=n) if USB is not needed in the deployed product.
• For nRF52 BLE firmware development including power optimisation, PPK2-guided profiling, and System OFF state machine design, Zeus Design delivers complete low-power firmware stacks for battery-operated IoT and wearable products.