This section will cover the default bootloader in the nRF Connect SDK: MCUboot. In addition, we will learn about MCUmgr and DFU Target, two libraries used for DFU in nRF Connect SDK.

Official documentation on Bootloaders and DFU in the nRF Connect SDK can be found at Bootloaders and Device Firmware Updates.

MCUboot

MCUboot is a bootloader created by Apache Mynewt, which is forked by Zephyr. The nRF Connect SDK uses a downstream version of MCUboot Zephyr fork. For official documentation, see Using MCUboot in nRF Connect SDK.

To enable MCUboot in a nRF Connect SDK, simply add CONFIG_BOOTLOADER_MCUBOOT=y to the project. The build system will then add MCUboot as a child image to the application. This does not add any DFU functionality. By default, adding MCUboot will partition the device with dual slots, as seen below:

Here, the slots are named: mcuboot_primary, and mcuboot_secondary. To only have one slot: mcuboot_primary, enable CONFIG_SINGLE_APPLICATION_SLOT for the mcuboot child image, for example, in child_image/mcuboot.conf. We will have a closer look at this in the exercises.

Note that CONFIG_SINGLE_APPLICATION_SLOT does not point to our Kconfig search, but instead to the MCUboot application files. MCUboot is technically an example, and the Kconfig search does not list example-specific configurations. Therefore, we must use the Kconfig files of MCUboot directly to browse its configurations. Alternatively, we can use nRF Kconfig GUI in VS Code. This lists all Kconfig options available for the child image, including MCUboot-specific options.

Firmware images for DFU must be formatted correctly and signed. For this, MCUboot provides a script called imgtool.py. In the nRF Connect SDK, this tool is used automatically in the build to generate MCUboot output build files. app.update is the default used for DFU. If we want to see how exactly the build system generates this file, we can build from the command line with west -v build ....

When MCUboot uses two slots, new firmware images are sent to mcuboot_secondary during DFU. MCUboot will then swap images if the secondary slot has a flag for Test or Confirm. These flags can be set either from the application, on the image itself before uploaded, or by the uploading tool.

If an image is tagged as “confirm”, MCUboot will swap it into the primary slot permanently.
If an image is tagged as “test”, MCUboot will swap it into the primary slot for one reset cycle. Unless the image is then confirmed while running, MCUboot will swap back the old application to the primary slot on its next reset. We will try out both modes in the exercises.

Libraries/tools related to DFU and FOTA

MCUmgr

To enable DFU in the application over the Serial protocol or Bluetooth Low Energy, the nRF Connect SDK uses the Zephyr Device Management services. The software subsystem used is specifically named MCUmgr. Kconfig options for mcumgr is listed in the previous link, but we can also look up “MCUMGR” in our Kconfig search.

DFU Target and FOTA Download

The DFU Target library is an nRF Connect SDK-specific library that handles firmware updates. DFU Target will check which type of update it receives and then handle it accordingly. For example, DFU Target will write application updates used with MCUboot to the mcuboot_secondary slot. Or if DFU Target receives a modem delta upgrade, DFU Target will hand the new firmware directly to the modem.

While the mcumgr library handles both transport and writing to memory, DFU Target does not handle transport. For applications connected to the internet, the nRF Connect SDK provides the FOTA download library, which first downloads firmware using HTTP(S) and hands the received firmware image to DFU Target.

If needed, it is possible to transfer firmware updates in a custom manner and use DFU Target manually from the application. We will not cover that in this course.

MCUboot and DFU documentation

Documentation and samples relevant to MCUboot and DFU are a bit spread around, so we will sum up some here.
First, an overview of bootloaders and DFU in the nRF Connect SDK can be found at Bootloaders and Device Firmware Updates.

Then we have the MCUboot documentation, which is inherited from the upstream MCUboot repository and is not nRF Connect SDK specific. (1) We have some changes to this documentation in the nRF Connect SDK, most notably Using MCUboot in nRF Connect SDK (2), which gives an overview of how to use MCUboot with the nRF Connect SDK specifically.

In addition to these pages, we have device-specific documentation on how to do DFU for each device under Device configuration guides. For example Developing with nRF52 Series: FOTA updates.

We will have a closer look at samples in the exercises section, but to mention a few: For general Zephyr MCUboot and mcumgr, see the SMP Server sample. nRF Connect SDK specific samples often have the option to enable MCUboot and DFU in them. For example, Bluetooth: Peripheral LBS sample or the Matter door lock. We have a couple of tests for MCUboot in the nRF Connect SDK as well, which can be helpful.

For the nRF91 Series and nRF70 Series, we have the FOTA Download docs. Then we have FOTA-specific sections under the different cloud providers, such as nRF Cloud: FOTA Updates, AWS FOTA and Azure FOTA.

In addition to these, several of our cellular and networking samples have FOTA support.