nRF

Nordic Semiconductor's nRF52 and nRF53 series are the dominant choice for Bluetooth Low Energy (BLE) products demanding ultra-low power consumption, small form factor, and a mature BLE stack. nRF devices are found in medical wearables, industrial sensors, asset trackers, and any application where BLE and power budget are the primary constraints.

What Is the nRF Platform?

Nordic's nRF family centres on two main series for embedded BLE products:

• nRF52 series — ARM Cortex-M4F (FPU) at up to 64 MHz, BLE 5.x, 802.15.4 (Thread/Zigbee on nRF52840), integrated DCDC, and extensive analog peripherals. The nRF52832, nRF52840, and nRF52833 are the most widely used devices.
• nRF53 series — dual ARM Cortex-M33 cores (application and network); the application core runs the user application while the network core runs the BLE/802.15.4 stack. Higher performance and security (TrustZone) than nRF52.
• nRF Connect SDK — Nordic's unified SDK based on Zephyr RTOS, covering both nRF52 and nRF53 series (as well as LTE-M/NB-IoT devices like the nRF9160).

This subtopic is part of the Embedded Systems topic.

Why Choose the nRF Platform?

• Ultra-low power — nRF52 series devices consume as little as 2.4 µA in BLE advertising (1s interval) and sub-1 µA in System OFF mode, making them the standard choice for coin-cell and energy-harvesting applications.
• BLE stack (SoftDevice or Zephyr BLE) — Nordic's SoftDevice is a certified, closed-source BLE stack that runs as a pre-compiled binary. The Zephyr-based BLE stack in nRF Connect SDK is open-source and supports the same BLE profiles.
• Regulatory certification — Nordic's certified modules (nRF52-based modules from many vendors, including Nordic's own) carry BT-SIG, FCC, CE, and ACMA certification, simplifying market access.
• DFU support — the nRF5 bootloader with DFU-over-BLE is well-documented and widely used for field firmware updates without physical access to the device.

Key Concepts

• SoftDevice — Nordic's pre-compiled, certified BLE protocol stack for the nRF52 series. Runs at higher priority than the application and provides the BLE API via a call-gate mechanism (SVC calls). The SoftDevice occupies a fixed region of flash.
• Zephyr RTOS — the open-source RTOS used by nRF Connect SDK. Zephyr's BLE stack (NimBLE-based or Zephyr's own stack) provides an alternative to the SoftDevice for nRF52 targets and is the required stack for nRF53.
• nRF Connect SDK — Nordic's unified development framework based on Zephyr and CMake. Required for nRF53; supported but optional for nRF52 (where the older nRF5 SDK is still available for legacy projects).
• BLE advertising — the mechanism by which a BLE peripheral broadcasts its presence and data. Advertising interval and payload determine power consumption and latency-to-connection.
• DCDC converter (nRF52) — the nRF52 series includes an internal DCDC step-down converter for the core supply. Enabling it reduces current consumption significantly compared to the default LDO mode; requires an external inductor (typically 10 µH at the appropriate pad).
• nRF52840 USB — the nRF52840 includes a native USB 2.0 full-speed interface, enabling USB HID, CDC serial, and DFU over USB in addition to BLE.

Common Tools and Software

• VS Code with nRF Connect SDK extension — Nordic's official IDE integration for nRF Connect SDK; provides project creation, build, flash, and J-Link debug integration. The recommended environment for all new nRF52 and nRF53 development.
• nRF Connect SDK — Nordic's unified development framework based on Zephyr RTOS and CMake. Supports nRF52, nRF53, nRF91 (LTE-M), and nRF70 (Wi-Fi) series. Required for nRF53; supported for nRF52.
• nRF5 SDK — Nordic's legacy SDK for nRF52 series (bare-metal + SoftDevice). Still in active use but superseded by nRF Connect SDK for new designs.
• J-Link — SEGGER's debug probe, Nordic's recommended adapter for nRF52/53 development. Available standalone (J-Link BASE, J-Link MINI) or integrated into Nordic DK (Development Kit) boards as J-Link OB.
• Nordic PPK2 (Power Profiler Kit 2) — Nordic's USB current measurement tool; measures nRF supply current at up to 1 MSPS with the nRF Connect for Desktop companion app. Essential for validating and optimising BLE power consumption.
• nrfutil — Nordic's command-line tool for DFU package creation, device programming, and BLE OTA firmware update management.

Common Mistakes

• Not enabling the DCDC converter — the nRF52 series includes an internal DCDC step-down converter for the core supply voltage. The DCDC mode must be enabled in firmware (NRF_POWER->DCDCEN = 1 or via the nRF Connect SDK power management configuration) and requires an external 10 µH inductor on the DCC/DCCDEC pins. Leaving the DCDC disabled means the core supply runs from the LDO, consuming 3–5× more current in sleep.
• Advertising interval too short for battery life targets — BLE advertising power is proportional to advertising rate. A 100 ms advertising interval consumes roughly 10× more power than a 1 s interval. Design the advertising interval to the longest value the application use case allows; measure with a PPK2 rather than estimating.
• SoftDevice not initialised before BLE API calls — the SoftDevice must be enabled and initialised before any BLE API call. Calling sd_ble_...() functions without a running SoftDevice causes a hard fault. In nRF Connect SDK, the BLE stack is initialised by the Zephyr BLE subsystem; in the nRF5 SDK, softdevice_enable() must be called before any SoftDevice API use.
• Not accounting for memory partitioning between SoftDevice and application — the SoftDevice occupies a fixed region at the bottom of the nRF52's flash and a reserved region of RAM. The application linker script must be configured to start above the SoftDevice boundaries. CubeMX does not exist for nRF; the flash/RAM partition is set in the application's linker script or nRF5 SDK configuration.
• Measuring power consumption without an actual BLE connection — power consumption during BLE advertising, connection, and notification intervals differs substantially. Measure with a PPK2 during a realistic operating scenario (establish a connection, send data at the expected rate, return to advertising) rather than measuring one state in isolation.

Common Questions

What is the difference between nRF5 SDK and nRF Connect SDK?

The nRF5 SDK is Nordic's legacy bare-metal + SoftDevice SDK, used for nRF52 series. It provides peripheral drivers, SoftDevice API wrappers, and common application examples without a RTOS (though FreeRTOS is supported as an add-on). The nRF Connect SDK is Nordic's newer unified framework based on Zephyr RTOS and CMake; it supports nRF52, nRF53, nRF91 (LTE), and nRF70 (Wi-Fi) in one toolchain. New projects should generally use nRF Connect SDK unless there is a specific reason to stay with the nRF5 SDK. Migration from nRF5 SDK to nRF Connect SDK is not trivial — plan for significant code rework.

How do I achieve the ultra-low power BLE advertising the datasheet claims?

Enable the DCDC converter (requires an external 10 µH inductor on the DCC/DCCDEC pins). Use the longest advertising interval your application allows — advertising power is proportional to advertising rate, so 1-second advertising intervals consume roughly 10× less than 100 ms intervals. Turn off unused peripherals and put the nRF into System ON + low-power sleep between advertising events. Measure actual current with a Nordic PPK2 (Power Profiler Kit 2) rather than estimating from parameters — the actual waveform often reveals unexpected wakeup events.

Does the nRF52 work with a standard CMSIS-DAP SWD probe?

Yes. The nRF52 series uses SWD for debugging and programming. Nordic recommends and sells J-Link-based probes (including the J-Link OB on their DK boards), but any CMSIS-DAP compatible SWD probe and OpenOCD with the nRF52 target configuration works. The nRF Connect extension for VS Code integrates J-Link natively. Zeus Design develops nRF BLE firmware for wearable and IoT products.

Knowledge Base

nRF Platform Foundations

• Nordic nRF Series Compared: nRF52 vs nRF53 vs nRF91 — when to choose each series: nRF52 (BLE/Thread), nRF53 (LE Audio, dual-core), nRF91 (cellular LTE-M/NB-IoT/GNSS), and the nRF54 next-generation
• nRF52 Variants: nRF52840 vs nRF52833 vs nRF52832 Compared — comparison table, selection decision framework, Zephyr RAM sizing, and module vs bare-die guidance for each nRF52 variant
• How Do You Choose a Microcontroller? — the selection framework for evaluating nRF vs ESP32 vs STM32 for BLE applications
• What Is an RTOS? — nRF Connect SDK is based on Zephyr RTOS; understanding tasks, threads, and the Zephyr API is essential
• What Is a Bootloader in Embedded Systems? — the nRF52/53 bootloader with DFU-over-BLE is a standard field update mechanism

SDK and Toolchain

• How Do You Set Up the nRF Connect SDK and Zephyr RTOS for nRF52 Development? — west workspace creation, Kconfig configuration, CMakeLists.txt project structure, west build/flash, and first-project pitfalls

BLE Development

• How Do You Implement a BLE Peripheral with Custom GATT Services on nRF52 Using Zephyr? — BT_GATT_SERVICE_DEFINE, UUID declaration, read/write handlers, CCCD for notifications, connection management, and notify vs indicate trade-offs

USB and Firmware Updates

• How Do You Use the nRF52840 USB Port and Update Firmware Over DFU? — native USB 2.0 hardware requirements, CDC ACM serial, MCUboot dual-slot partitioning, imgtool image signing, and DFU trigger workflow

BLE and Wireless

• Bluetooth vs Wi-Fi vs LoRa vs Zigbee: Which Protocol Should You Use? — comprehensive BLE comparison against other wireless protocols
• What Antenna Types Are Used in Embedded Wireless Designs? — antenna selection for BLE 2.4 GHz applications; chip vs PCB trace vs external

Power and Debugging

• How Do You Minimise Current Draw on an nRF52 in BLE Applications? — DCDC converter, advertising and connection interval tuning, System OFF mode, Zephyr power management, peripheral disable, and PPK2 measurement
• How Do You Debug Embedded Firmware? — SWD debugging applies to nRF52/53; J-Link (Nordic's recommended debug probe) is supported by nRF Connect SDK

Forum Discussions

• nRF5340 network core not starting — BLE stack hangs on bt_enable after migrating from nRF52840 — CONFIG_BT_HCI_IPC=y, dual-core architecture (app core + network core hci_ipc), multi-image build, and nRF52840→nRF5340 migration checklist
• nRF52840 BLE advertising not starting — device not showing up in scanner after bt_enable completes — Kconfig checklist (CONFIG_BT=y, CONFIG_BT_PERIPHERAL=y), checking bt_le_adv_start return values, UART console setup, board target verification, and the async callback form of bt_enable