The nRF5 SDK for Mesh bootloader enables Bluetooth mesh devices to update their application, SoftDevice, or bootloader across a mesh network with over-the-mesh Direct Firmware Updates. The bootloader is capable of relaying while receiving, allowing all devices in the mesh network to receive the update at the same time.
The bootloader supports DFU transfers occurring while the application is running, significantly reducing application downtime during updates.
Table of contents
The bootloader is limited to 22 kilobytes flash and 768 bytes RAM. In addition to the 22 kilobytes flash, the bootloader reserves the two last pages of the flash. This means that the total size of the bootloader is 32 kilobytes for the nRF52 Series and 24 kilobytes for the nRF51 Series. The actual size of the bootloader depends on whether it is compiled with the serial (UART) transport in addition to toolchain and optimization settings.
The nRF5 SDK for Mesh bootloader is compatible with the same Bluetooth mesh stack configurations as the nRF5 SDK for Mesh. For details, see the Compatibility page.
See The toolchain document for the required tools for building and using the bootloader. Pre-compiled variants of the bootloader are available in the bin/
folder. Building the bootloader is only supported with the CMake build system and can be enabled with the BUILD_BOOTLOADER
CMake option. Be aware that the bootloader must be built with CMAKE_BUILD_TYPE
equal to MinSizeRel
for it to fit within its flash size requirement.
To get started with the proprietary mesh DFU, see the proprietary mesh DFU quick start guide. It is recommended that all new users go through this guide, and use the steps as a basis for their DFU procedure.
The bootloader supports both serial and over the air transfers. The intended main usage scenario is to have a single device in a network connected to a host over a serial connection, controlled via the Bluetooth mesh version of nRF Util PC tool. From this device, all devices in the network may receive any firmware updates over the Bluetooth mesh. All update packets are flooded across the Bluetooth mesh, and all devices in the network are updated at the same time.
The nRF5 SDK for Mesh bootloader allows for signed DFU transfers, using 256 bit ECDSA. Signing DFUs prevents attackers from hijacking a device by flashing their own firmware to it. While not enforced, it is strongly recommend to give your device a signing key before deploying a product, as this allows for better security, without any significant overhead.
The DFU transfers are signed by a private key, generated by the Nordic Semiconductor's nRF Util PC tool (see the quick start guide for details), and each device has a copy of the public key to verify a signature added to the end of signed firmwares. Under no circumstance should the private signing key be shared with a third party or be present in the device firmware. You may choose to use a single signing key for each application, or use the same key for all applications.
The nRF5 SDK for Mesh bootloader is capable of receiving and relaying DFU transfers while the application is running. When a transfer has finished, the DFU module goes idle, and notifies the application of the new firmware bank. The application may choose to inspect the firmware, alter it, or do some additional validation, then flash it at any time. After flashing a banked firmware, the old firmware is no longer available on the device, and any rollbacks have to be executed as a new update.
The bootloader is also capable of operating without an application, as a recovery mechanism from a faulty application.
Since the DFU operation is the same whether the device is operating in application or bootloader mode, the DFU module in the bootloader has been separated from the rest of it, and is made callable from the application. This sharing is implemented in a similar manner to the Softdevice, where the application is expected to reserve some RAM for it, without linking it. Access to the DFU module goes through a single entry point, which is located by the application side framework upon initialization.
A couple of limitations to the bootloader applies: