nRF Util v6.1.0

DFU package combinations

The following table lists the supported combinations when generating a Device Firmware Update (DFU) package.

Table 1. Supported Bootloader, SoftDevice, and Application combinations
Combination Supported
Bootloader (BL) Yes1
SoftDevice (SD) Yes2
Application (APP) Yes
BL + SD Yes
BL + APP No3
BL + SD + APP Yes4
SD + APP Yes2,4

1Use nRF Util v5.0.0 or later when creating update packages of bootloaders compiled from nRF5 SDK 15.3.0 or later to ensure the correct size of generated packages.

Update packages of external applications (e.g. updates for third-party applications) are generated with the --external-app option. When this option is set, the receiving device stores the update but will not activate it. This functionality is experimental in the nRF5 SDK and is not yet used in any examples.

The --zigbee boolean option generates the Zigbee update file in addition to the zip package. For example:

nrfutil pkg generate --hw-version 52 --sd-req 0 --application-version 0x01020101 --application nrf52840_xxaa.hex --key-file ../priv.pem --app-boot-validation VALIDATE_ECDSA_P256_SHA256 app_dfu_package.zip --zigbee True --zigbee-manufacturer-id 0xCAFE --zigbee-image-type 0x1234 --zigbee-comment good_image --zigbee-ota-hw-version 52 --zigbee-ota-fw-version 0x01020101 --zigbee-ota-min-hw-version 52 --zigbee-ota-max-hw-version 52

The --zigbee-ota-hw-version and --zigbee-ota-fw-version options refer to the generated image to be distributed to the Zigbee OTA Server and disseminated later into the network. The --zigbee-ota-hw-version and --zigbee-ota-fw-version options describe the hardware version and firmware version of the Zigbee OTA Server respectively. Each time the Zigbee OTA Server receives the image for the dissemination, its firmware version is updated. This is done to protect from a malicious attack, where an attacker could wear down the Server flash memory by repeatedly sending the full Zigbee image to be distributed. Thus, in order for the OTA Server to accept the image for dissemination, the value passed as a --zigbee-ota-fw-version has to be incremented with every transfer of the image.

The --zigbee-ota-min-hw-version and --zigbee-ota-max-hw-version options refer to the fields in the Zigbee OTA header, which determine the range of the OTA Client's hardware version for which the image is suitable. Both --zigbee-ota-min-hw-version and --zigbee-ota-max-hw-version are optional and if used, both must be given.

2The SD must be of the same Major Version as the old BL may not be compatible with the new SD.

3Create two ZIP packages.

4The SD (+ BL) + APP update is done with two consecutive connections, unless a custom bootloader is used. First the SD (+ BL) is updated, then the bootloader will disconnect and the (new) BL will start advertising. Then the second connection to the bootloader will update the APP.

However, the two SDs may have different IDs. The first update requires --sd-req to be set to the ID of the old SD. The APP update requires the ID of the new SD. The new ID must be set using --sd-id parameter. This parameter was added in nRF Util v3.1.0 and is required since v3.2.0 in case the package should contain SD (+ BL) + APP. Also, the new ID is copied to --sd-req list so that in case of a link loss during the APP update the DFU process can be restarted. In this case, the new SD would overwrite itself, so --sd-req must contain the ID of the new SD.