The following table lists the supported combinations when generating a Device Firmware Update (DFU) package.
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 |
1Update 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.
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.