Since the nRF5340 has two processor cores, DFU becomes more complicated. First, we need a dedicated bootloader for the network core. This is known as b0n. Secondly, the application core can not write directly to the network core flash. Therefore, the application core must send the image to the network core, before the network core writes the new image to its own internal flash. This transfer is done using our PCD library.

Luckily, our backend will take care of the complicated stuff, so as users, we only need to set the correct configurations to enable this. However, it is good to have some understanding of the concepts, so we will start by learning how the images are moved.

There are two ways of performing DFU for the nRF5340. Either we can update one core at a time, or we can update both cores simultaneously.

Non-simultaneous update

Updating the cores one at a time is very similar to single-core DFU. This is done in two steps: First, update the application core and then update the network core. As shown in the figures below, the first update updates the application core as normal.

Then for the next update, network core firmware is loaded into mcuboot_secondary and then it is transferred to the network core via the PCD drivers.

However, this method of updating is only recommended for serial DFU.

If the interface between the network core and the application core changes in an update, it will make the application unable to use the radio until both cores are updated. Therefore, this update is not well suited for FOTA, which uses the radio for DFU. Instead, we use simultaneous updates.

Simultaneous update

Documentation for how to enable this can be found at Simultaneous multi-image DFU.

To update both cores on the same reboot, we must save the new firmware updates for both the application core and the network core at the same time. To do this, we need an extra slot in non-volatile memory. We call this mcuboot_secondary1. Now we need to split our non-volatile memory into three: mcuboot_primary, mcuboot_secondary and mcuboot_secondary1. This will limit available memory for the application to use. To give the application more space, it is common to add external flash for mcuboot_secondary and mcuboot_secondary1. However, it is still possible to use internal flash for all slots for devices with small applications. The figure below illustrates the swap with external flash.

MCUboot slots must always come in pairs. Since we do not want to use non-volatile memory for mcuboot_primary1, we simulate this flash space instead. Then when MCUboot tries to swap the network core update into the simulated mcuboot_primary1, we instead swap the image to the network core over the PCD interface. See information about this in the note in our Simultaneous multi-image DFU docs.

Some of the exercises will have a nRF5340 section which will give steps on how to add nRF5340 DFU to that exercise. For example, we will learn how to do non-simultaneous DFU in the DFU over UART exercise and how to do simultaneous DFU in the FOTA over Bluetooth Low Energy exercise.