This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Version numbers for Secure DFU

Why do the version numbers have to be as follows for a merged hex file to be able to exit the dfu mode when flashed externally as a combined hex file (SD +BL + BL settings + App)?

nrfutil settings generate --family NRF52 --application app.hex --application-version 3 --bootloader-version 2 --bl-settings-version 1 app_valid_settings.hex

I would want the application version to start around 1 and move forward as we have OTA updates.

Also, how does the verification work on the nrfutil "application-version-string" option?

nrfutil settings generate --help

Usage: nrfutil settings generate [OPTIONS] HEX_FILE

Options:

--family [NRF51|NRF52] nRF IC family: NRF51 or NRF52

--application TEXT The application firmware file. This can be omitted if the target IC does not contain an application in flash. Requires --application-version or --application- version-string.

--application-version INTEGER The application version.

--application-version-string TEXT

                              The application version string, e.g
                              "2.7.31".

--bootloader-version INTEGER The bootloader version.

--bl-settings-version INTEGER The Bootloader settings version.

Defined in nrf_dfu_types.h, the following apply toreleased SDKs

                              |SDK12|1|  (SDK12 is 1).

--help Show this message and exit.

  • Hi Kevin,

    the version numbers given in the example have been chosen according to the acceptance rules of the bootloader and it is fully possible to have the application version set to 1. As far as I know there is no check for the application-version-string in dfu_handle_prevalidate() so must be implemented as a custom check by the user.

    Acceptance rules for versions

    Unless version validation is skipped, the dfu_handle_prevalidate() function applies the following acceptance rules to determine whether the image is accepted:

    • Hardware version: If the hardware version that is specified in the init packet matches the hardware of the device, the image is accepted.

    • SoftDevice Firmware ID: If one of the specified firmware IDs matches the ID of the current SoftDevice, the image is accepted.

    • Firmware version: If the image contains a bootloader, the image is accepted if the new firmware version is greater than (>) the existing version of the bootloader. If the image contains an application, the image is accepted if the new firmware version is greater than or equal to (>=) the existing version of the bootloader.

    This stated on this Infocenter page.

  • Should that last bullet be updated to something like "If the image contains an application, the image is accepted if the new firmware version is greater than or equal to (>=) the existing version of the application as recorded in the DFU Settings data."

  • The acceptance rules are copy/pasted from this Infocenter page.

  • I see that mentioned under the quoted block, but I don't think the source of the data changes its accuracy. I could certainly be wrong, but a quick examination of the code led me to my proposed update.

    Additionally, if the goal is to prevent downgrading to an older version of the application firmware, then checking whether an application version is greater than or equal to an unrelated application, the bootloader, seems pointless.

  • @jeffs: I agree that

    If the image contains an application, the image is accepted if the new firmware version is greater than or equal to (>=) the existing version of the bootloader.

    should be changed to

    If the image contains an application, the image is accepted if the new firmware version is greater than or equal to (>=) the existing version of the application.

    I have reported this internally so that it may be fixed.

Related