This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

how to define nrfutil's option?

Hi. I'm using nRF51822AC, SDK12.2.0, S130 v2.0.1 as central.

I want to make only app image for DFU. I made a command as below refering to github.com/.../pc-nrfutil.

nrfutil pkg generate --hw-version 51 --sd-req 0x87 --application-version 4 --application nrf51422_xxac.hex --key-file priv.pem app_dfu_package.zip

Is it right?

Q1. How can I define "--application-version"? I don't understand why it is 4 now.

Q2. Do I need to define "--bootloader-version" and "--bl-settings-version" as below? nrfutil settings generate --family NRF51 --application app.hex --application-version 3 --bootloader-version 2 --bl-settings-version 1 sett If yes, how can I define?

Q3. If Q2 is yes, regarding "nrfutil settings generate" When do I have to execute? nrfutil pkg generate --> nrfutil settings generate? or nrfutil settings generate --> nrfutil pkg generate?

I need your help.

  • Hi Roger,

    The script you found on github is just an example of how to generate a dfu package.

    Q1. So number 4 is just a number given as an example. By default we start with fw_version = 0 . The bootloader will reject DFU package if the new fw_version < current fw_version. So it's up to you to decide the fw_version (application-version). Just make sure new DFU package should have higher or at least equal application-version/fw_version.

    Q2. You only add --bootloader-version when you update the botloader. Same rule applies for bootloader version, we start with 0. But the rule is a little bit stricter the new version must be > the current version. --bl-settings-version only requires when you generate bootloader setting, we currently only have one version = 1.

    Q3. "nrfutil settings generate" needed when you want to generate a setting hex that patch the bootloader to accept the application as a valid application. For example when you want to flash all bootloader, softdevice, application from your programmer you need to generate and flash the bootloader setting to tell the softdevice to accept the application. By default the bootloader only accept the application that it receives via OTA/Serial DFU.

  • Thanks for your reply. I have more question for Q1. Originally, fw hex file download without DFU. So I don't use "--application-version" before I make DFU image. How can I know current fw_version before DFU? Is it 0? Even it's 0, please tell me how to know current fw_version.

    More question! And here is serious problem. I made image for DFU. And it worked very well using smartphone. But after i erased device as below "nrfjprog --eraseall"(because I wanted to erase UICR), it doesn't work again. I did backup all well-operating hex files(boot.hex, app.hex) and image file for DFU. Even i download them, it doesn't work. What could be the problem?

    And in this case how can I debug using keil? for example how can I know PK is right or not? how can I know hw version is ok or not? how can I know sd version is ok or not? how can I know app version is ok or not?

  • Yes it's 0. If you don't do DFU OTA update it won't be changed to anything else, regardless what application you flashed on your chip via programmer.

    The bootloader is not a black box, the source code is available, you can have a look. Just do a full search (Find in Files) for "fw_version" you can find where it's used and how.

    After you do "nrfjprog --eraseall", have you flashed the softdevice back ?

    You can debug the bootloader in KEIL and can find how the all the versions works. There is nothing special here, simply we check in the init packet, if the sd version is match with what we have on the chip, if app version is >= current version (stored in bootloader setting) on the chip.

Related