DFU package combinations

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

¹Update packages of external applications (for example, 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 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-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 --zigbee True

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, for the OTA Server to accept the image for dissemination, the value passed as a --zigbee-ota-fw-version must 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.

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

³Create two ZIP packages.

⁴The 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.