nRF52 Variants Compared: Which Should You Choose for Your BLE Product?

Detailed Explanation

Nordic Semiconductor's nRF52 series is the dominant platform for Bluetooth Low Energy (BLE) products demanding ultra-low power, small form factor, and a production-ready BLE stack. All nRF52 variants share the same core architecture — an Arm Cortex-M4F at 64 MHz, an integrated 2.4 GHz radio supporting BLE 5.x, and a set of analog and digital peripherals — but differ in flash and RAM size, USB availability, 802.15.4 radio support, BLE Long Range (Coded PHY) capability, and package options.

Choosing the wrong variant early adds cost at respin — particularly if the 52832's 64 KB RAM proves insufficient for the firmware stack. All specifications cited in this page are typical values from Nordic Semiconductor product pages and datasheets; verify against the specific product specification revision applicable to your design before finalising the schematic.

nRF52 Variant Comparison

All variants include an Arm Cortex-M4F core (with FPU), BLE 5.x support for 1 Mbps and 2 Mbps PHY, and an integrated DCDC step-down converter for the core supply (requiring an external 10 µH inductor). Refer to the Nordic Semiconductor product page for current GPIO counts, package options, and exact peripheral availability per variant.

nRF52840 — The Default Choice for New Designs

The nRF52840 is Nordic's flagship nRF52 device. Its 1 MB flash and 256 KB RAM make it the most comfortable variant for the nRF Connect SDK and Zephyr RTOS: a typical Zephyr + BLE peripheral image uses 40–60 KB RAM, leaving substantial headroom for application data, FreeRTOS tasks (if used in addition to Zephyr), and MCUboot dual-slot OTA.

The nRF52840 is the only nRF52 variant with a native USB 2.0 Full Speed interface, enabling USB HID, USB CDC ACM serial, and DFU-over-USB without a separate USB-to-UART bridge — for the full USB peripheral setup and MCUboot DFU configuration, see nRF52840 USB and firmware update over DFU. It is also the only variant offering the full combination of BLE 5.0 (1M, 2M, and Coded PHY), 802.15.4 (Thread, Zigbee, and therefore Matter), and NFC tag emulation in a single die. For new products where the requirements are not fully locked down, the nRF52840 reduces the risk of late-stage hardware revisions due to capability constraints.

nRF52833 — 802.15.4 Without USB

The nRF52833 retains the nRF52840's radio capabilities (BLE 5.0 with Coded PHY, 802.15.4 for Thread and Zigbee) at lower unit cost, sacrificing the USB interface and reducing RAM to 128 KB. For mesh networking applications where USB is not needed and memory usage has been validated to fit in 128 KB, the 52833 is a cost-optimised alternative to the 52840.

The 128 KB RAM limit warrants careful profiling. A Zephyr image running a BLE peripheral and a Thread stack simultaneously will consume a significant fraction of available RAM; plan memory partitioning explicitly rather than discovering the constraint at integration time.

nRF52832 — The Most-Deployed nRF52

The nRF52832 is the most widely deployed nRF52 variant and the one most commonly found in third-party certified modules, legacy reference designs, and existing production codebases. Two flash configurations exist:

• nRF52832-QFAA — 512 KB flash, the standard choice
• nRF52832-QFAB — 256 KB flash, for the most cost-constrained applications

Both have 64 KB RAM. The nRF52832 lacks three capabilities that are sometimes needed late in a project:

• No USB — firmware updates require UART, SWD, or DFU over BLE; there is no USB device mode
• No 802.15.4 — Thread, Zigbee, and Matter-over-Thread are not available; a separate co-processor or module is needed for these protocols
• No LE Coded PHY — the nRF52832 supports BLE 5.0 at 1 Mbps and 2 Mbps PHY but not the Coded PHY (Long Range) mode at 125 kbps or 500 kbps; if your application requires BLE range beyond approximately 100 metres, the 52832 is the wrong choice

64 KB RAM is the constraint most likely to cause problems. A minimal Zephyr + BLE peripheral application can fit in 40–50 KB RAM, but complex applications with large GATT tables, multiple simultaneous connections, or significant application state may exceed this. Profile early; a 52832→52840 change late in development requires PCB revision.

nRF52811 and nRF52810 — Entry-Level Parts

The nRF52811 and nRF52810 are minimal nRF52 devices with 192 KB flash and 24 KB RAM. The 52811 adds 802.15.4 capability; the 52810 is BLE-only. At 24 KB RAM, these variants are too constrained for the Zephyr RTOS and are typically used with the legacy nRF5 SDK in a bare-metal or FreeRTOS configuration. OTA firmware updates via BLE DFU are not practical at this RAM size without substantial engineering effort. These parts suit fixed-function applications: BLE beacons, temperature sensors with no update requirement, and asset trackers where minimising current draw and cost takes absolute priority over flexibility.

SDK: nRF Connect SDK vs nRF5 SDK

All new nRF52 designs should target the nRF Connect SDK (NCS), which is based on Zephyr RTOS and CMake. NCS is required for nRF53 targets and is Nordic's stated direction for all future development. It provides the Zephyr BLE subsystem, Zephyr's power management framework, MCUboot for OTA updates, and a consistent toolchain across the entire nRF product line.

The nRF5 SDK (legacy) with SoftDevice BLE stack still supports nRF52 and remains in active production use in existing designs, but Nordic has moved it to maintenance-only: no new major features, and the SDK does not support newer nRF5x SoCs. Starting a new project in the nRF5 SDK creates long-term technical debt — plan to use NCS for any design entering development today.

Migration from nRF5 SDK to nRF Connect SDK is a significant effort at the BLE stack API layer. The SoftDevice call-gate API (sd_ble_...) has no equivalent in Zephyr; the application BLE logic must be rewritten against the Zephyr BLE API.

See How Do You Set Up the nRF Connect SDK and Zephyr RTOS for nRF52 Development? for the full west workspace setup, project structure, build, and flash workflow. Once the toolchain is running, implementing a BLE peripheral with custom GATT services is the typical next step for most BLE product designs.

Module vs Bare Die

For products sold in Australia, the ACMA RCM (Regulatory Compliance Mark) is required for devices with integrated radio. A pre-certified nRF52840 or nRF52832 module from vendors including Laird, u-blox, Fanstel, and Raytac typically carries BT-SIG, FCC Part 15, CE, and module-level ACMA certification, allowing the system integrator to use the module vendor's approval for the radio subsystem rather than performing a full RF certification cycle. The module's ACMA certification covers intentional BLE emissions only — the complete product still requires CISPR 32 EMC testing for non-intentional emissions from the host board before RCM marking; see what a pre-certified module's ACMA certification covers for RCM compliance. The trade-off is higher unit cost and reduced ability to customise the RF circuit.

Bare-die designs offer lower unit cost at volume, full antenna flexibility, and a smaller footprint (in WLCSP package for the nRF52840), but require a custom RF layout, antenna design, and full regulatory certification. For early-stage products and lower volumes, a pre-certified module is almost always the lower-risk path.

Design Considerations

• Default to nRF52840 for new designs. The additional cost over the 52832 is modest at typical engineering quantities, and the RAM headroom eliminates the most common cause of respin. Downgrade to a smaller variant only after RAM and peripheral requirements are validated in firmware.
• Thread/Zigbee/Matter requires 52840 or 52833. The 802.15.4 radio is a fixed hardware feature, not a software option. If the product roadmap includes a Matter variant or Thread border-router connectivity, the 52832 cannot be used.
• Enable the DCDC converter. The nRF52 series includes an internal DCDC step-down converter for the core supply; enabling it requires an external 10 µH inductor on the DCC/DCCDEC pins and a firmware configuration change. Leaving the DCDC disabled (LDO mode) typically increases active-mode current by 3–5×. This applies to all nRF52 variants. For a complete current-draw optimisation guide — covering DCDC mode, advertising interval tuning, connection interval, and System OFF wake configuration — see nRF52 power optimisation for BLE applications.
• Zephyr RAM overhead is real. The Zephyr RTOS, BLE stack, and MCUboot together occupy a significant portion of available RAM. Budget 40–60 KB for the infrastructure before counting application requirements. This makes 64 KB (nRF52832) tight and 128 KB (nRF52833) workable but measured. The nRF52840 (256 KB) provides genuine headroom.
• Long Range BLE needs Coded PHY hardware. The 52832 is the only common nRF52 variant that lacks Coded PHY support. If range beyond approximately 100 m in open space is a requirement — or even a future option — do not design on the 52832.

For nRF52 firmware development including nRF Connect SDK / Zephyr RTOS bring-up, BLE GATT profile implementation, and MCUboot OTA, Zeus Design delivers complete firmware stacks for wearable and IoT products.

Common Mistakes

• Choosing the nRF52832 for its cost, then running into 64 KB RAM limits. A Zephyr + BLE + application image that fits in 40 KB on the test bench can grow to 60 KB+ once GATT tables are populated, connection event buffers are allocated, and application state is added. Profile memory usage before committing the schematic.
• Starting a new design on the nRF5 SDK. The nRF5 SDK is in maintenance mode. Future hardware (nRF53, nRF91, nRF70) is only supported in nRF Connect SDK. Choosing the nRF5 SDK today means a full rewrite when the SoC is upgraded.
• Not enabling the DCDC converter. Leaving the internal DCDC disabled forces the core supply to run through the on-chip LDO, consuming significantly more current in both active and sleep modes. The DCDC requires a 10 µH external inductor on the DCC/DCCDEC pins — it is not an optional optimisation, it is part of the standard circuit for any power-conscious design.
• Assuming the nRF52832 supports Long Range BLE. Engineers familiar with the nRF52840's Coded PHY sometimes assume it carries over to the 52832. It does not. If a range-critical application is designed on the 52832 and Long Range is later deemed necessary, the only fix is a board respin to the 52840 or 52833.
• Overlooking certified module options for ACMA compliance. A custom nRF52 RF circuit requires full radio certification before sale in Australia. A pre-certified module from a Nordic partner eliminates most of the regulatory burden and substantially reduces the time to market for the radio subsystem. For the full compliance scope — what the module's certification covers and what the host board must still address — see pre-certified radio module RCM compliance.