Two devices are required to perform a Device Firmware Update: the DFU target and the DFU controller. The DFU target is the device that is updated with a new firmware image, which can contain a new application, SoftDevice, bootloader, or a combination of SoftDevice and bootloader. The DFU controller is the device that transfers the image. For example, the DFU controller can be a mobile phone running an app, or an nRF5 Development Kit in conjunction with nrfutil.
The DFU target is the device that runs the DFU having at least one active DFU transport. It can be the bootloader in DFU mode, or an application with DFU running in the background (DFU over TFTP example). The DFU controller can then initiate the transfer of a firmware image, which is received and validated by the DFU target. If the image is valid, the device resets and the bootloader activates the image to replace the existing firmware. Depending on the type of the image, it might replace the application, the SoftDevice, or even the current bootloader that is receiving the update. See Dual-bank and single-bank updates for detailed information about where the image is stored and how it is copied.
As the DFU controller, you can use the following Nordic tools:
nrfutil(version 2.2.0 or later)nRF Connect for Desktop- Nordic's mobile apps, such as
nRF Connect for Mobile.
The DFU modules can be used to implement the DFU target. The following flow chart shows the required steps for a firmware update, which must be implemented in the DFU target:
The events and procedures for the firmware update process are agnostic of the transport protocol that is in use. The DFU modules contain implementations for BLE, UART, and USB CDC (see DFU protocol). The DFU controller can trigger the events by sending a corresponding message on the DFU transport.
DFU procedure
The nrfutil tool generates a zip file which contains one or two updates (see Creating a firmware package with nrfutil). A single update consists of an init packet with new firmware details and binary data. The DFU controller sends the init packet and waits for the confirmation from the DFU target. DFU target validates the init packet and responds with the result. On successful validation, DFU controller sends the binary data. Once binary data is received by the DFU target, postvalidation is perfomed. On successful validation, the DFU target resets and the bootloader activates the new firmware. If the zip file contains two updates, the DFU controller expects that the DFU target enters DFU mode and attempts to perform a second update by establishing a connection and sending the second init packet. From the perspective of a user of the DFU controller application, such update is perceived as single update, even though it is performed in two steps.
A single update may contain the following elements:
- the application,
- a SoftDevice,
- the bootloader,
- the bootloader and a SoftDevice.
If update must contain the application and a SoftDevice (and bootloader), then the zip package contains two updates. If the bootloader depends on Softdevice (see Bootloader dependencies) then package that contains Softdevice update may contain the bootloader.
After completion of the first step which ends with activation of the new SoftDevice (and the bootloader), application may still be valid but is not runnable because of broken SoftDevice dependency. It must be updated in the second step. After activation of a package with a SoftDevice, the bootloader will enter DFU mode expecting an application update. Since application update is optional (not required after SoftDevice minor version update), the inactivity timeout in the bootloader is set to a different (shorter) value than the default one (NRF_BL_DFU_CONTINUATION_TIMEOUT_MS).