How Does nRF52/53 Firmware Update Over BLE Work — MCUmgr/SMP vs Legacy Secure DFU?

Detailed Explanation

Most nRF52-family SoCs shipping in commercial products have no USB peripheral at all — the nRF52832, nRF52833, nRF52810, nRF52811, and nRF52820 are BLE/802.15.4 radios only. For these parts, and for any nRF52840/nRF5340 design that doesn't expose a USB connector to end users, BLE is the only practical field firmware-update path once a product has shipped. How to Use the nRF52840 USB Port and Update Firmware Over DFU covers the USB-cable case in depth; this page covers the wireless case that applies to the rest of the nRF52 family.

There are two genuinely different BLE DFU architectures in the Nordic ecosystem, and they are not interoperable — the mobile app, host tooling, and firmware Kconfig required depend entirely on which one the project is built on.

Legacy Secure DFU (nRF5 SDK)

Projects built on the older, non-Zephyr nRF5 SDK use Nordic's own Secure DFU bootloader and BLE service. The architecture:

• A DFU bootloader, based on Nordic's nrf_dfu bootloader project, occupies a dedicated flash region — conceptually similar to MCUboot's role but Nordic-specific rather than the vendor-neutral MCUboot used in NCS.
• The bootloader exposes a Secure DFU BLE Service (commonly UUID 0xFE59) when active, through which a connected central transfers a signed firmware package (a .zip produced by nrfutil pkg generate, containing the image, an init packet, and a signature).
• Entry into DFU mode is either via a physical button held during power-on, or via the Buttonless DFU characteristic — a GATT characteristic the running application exposes that, when written, tells the device to reset into the DFU bootloader without requiring physical access. This is what lets a phone app trigger a field update on a sealed, buttonless product.
• Image signing uses Nordic's nrfutil tooling with a private/public EC key pair, conceptually similar to MCUboot's imgtool but using Nordic's own package format rather than MCUboot's.

This is the model most existing nRF5 SDK-based products still in the field use, since the nRF5 SDK predates NCS and was Nordic's primary SDK for years.

MCUmgr/SMP (nRF Connect SDK)

Projects built on the newer, Zephyr-based nRF Connect SDK (NCS) — which is Nordic's current recommended SDK for all new designs — use a different, vendor-neutral architecture built on Zephyr's own subsystems:

• MCUboot (the same bootloader used for USB DFU on the nRF52840) manages the dual-slot image swap, regardless of which transport delivered the image.
• MCUmgr is Zephyr's device-management subsystem — a general-purpose management framework covering image upload, OS-level commands (reset, echo, task list), and other device operations, not specific to firmware update alone.
• SMP (Simple Management Protocol) is the request/response protocol MCUmgr speaks. SMP is transport-independent — the same protocol runs over BLE, UART, or USB CDC, using a Nordic-defined BLE GATT service to carry SMP packets when the BLE transport is enabled.
• Because the SMP server can run as part of the normal application (rather than requiring a dedicated DFU-only bootloader mode), a device can accept an image upload while continuing normal BLE operation, then apply the swap on a subsequent reset — there's no separate "enter DFU mode" step analogous to the legacy Buttonless DFU characteristic.

Enabling the BLE SMP transport in NCS involves the MCUmgr, SMP-over-Bluetooth, and image/OS management group Kconfig symbols (the exact symbol names have shifted across NCS versions — check the MCUmgr documentation for your specific NCS release rather than assuming one fixed symbol set), alongside the same MCUboot dual-slot partitioning and imgtool-signed image workflow already covered for the USB case.

Which One Applies to a Given Project

A device migrating from nRF5 SDK to NCS is effectively switching its entire field-update architecture, not just recompiling against a new SDK — mobile apps, backend update infrastructure, and any existing fleet-management tooling built against one protocol will not speak to devices running the other.

Design Considerations

• BLE DFU needs a connection budget, not just a protocol. A firmware image of several hundred kilobytes takes meaningfully longer to transfer over BLE than USB — plan the connection interval, ATT MTU, and PHY (2M PHY roughly doubles raw throughput over 1M) explicitly for the update use case; see BLE connection parameters and power optimisation for the trade-offs involved in requesting a faster connection during an update session.
• Test the fallback path, not just the happy path. Whichever architecture is used, MCUboot's test-swap-and-confirm model (or the legacy bootloader's equivalent) exists specifically to recover from a bad image — verify that a genuinely broken update actually triggers automatic rollback in your firmware, not just in theory.
• Decide the DFU architecture before, not after, choosing an SoC that lacks USB. If a product needs both a wired factory-programming path and a wireless field-update path, and the target SoC (nRF52832, for example) has no USB, the BLE DFU architecture becomes the only field-recoverable path — any gap in its reliability has no wired fallback once the product has shipped.
• A locked-down production device still needs some way to trigger an update. If RDP-equivalent flash protection or a locked debug port is in place, the BLE DFU path (whichever architecture) becomes the sole recovery mechanism for a bricked field unit — make sure it's tested against exactly the failure modes it will need to recover from.

Common Mistakes

Assuming "DFU over BLE" is one protocol

Nordic's Secure DFU and MCUmgr/SMP are architecturally different systems with different BLE services, image formats, and mobile app requirements. A mobile app or backend built for one will not discover or update a device running the other — check which SDK generation a given firmware image was built on before assuming compatibility.

Not accounting for BLE's lower throughput when sizing the update window

A field device on a battery budget that assumes a USB-speed update duration when planning a maintenance window (e.g. "update happens during a 10-second scheduled wake") can under-provision the time actually required over BLE, especially at default (non-optimised) connection parameters.

Migrating from nRF5 SDK to NCS without a migration plan for the update mechanism itself

Because the bootloader, BLE service, and image format all change together, a fleet of nRF5 SDK devices in the field cannot be silently switched to NCS-based firmware via a normal update — the last nRF5 SDK update must itself either be the final firmware for those units, or must include a deliberate one-time bridge to install an NCS-compatible bootloader, which is a substantially more involved (and riskier) operation than a routine application update.

Leaving the SMP/Secure DFU service permanently discoverable and unauthenticated in production

Both DFU architectures support pairing/bonding and (for MCUmgr) additional application-level authentication of management commands. A production device that leaves its management/DFU service open to any nearby central without requiring a bonded, authenticated connection accepts firmware images from anyone in range — see BLE pairing and security in embedded products for the bonding and authentication mechanisms that should gate access to either DFU path.

If you're choosing between the legacy and modern Nordic DFU stacks for a new nRF52/53 product — or migrating an existing fleet between them — Zeus Design's embedded firmware team designs BLE field-update architectures across the full Nordic SoC range.