Generating DFU package for Bootloader image

[beemavishnu]

Hi,

 

I am using nRF52840, S140 V7.0.1.

I am using Secure Serial Bootloader and able to do DFU of Application.

 

DFU of application

Using below command able to generate DFU package.

nrfutil pkg generate --hw-version 52 --application-version 2 --application ble_app_blinky_pca10056_s140.hex --sd-req 0xCA --key-file private.key BLE_Beeper_V2_package.zip

 

Once Package is generated, able to do DFU via below command

nrfutil dfu serial -pkg BLE_Beeper_V2_package.zip -p COM8 -b 115200 -fc 0

 

DUF of Bootloader

Now I am trying to do the same for generating Bootloader package. Generate Bootloader DFU package

nrfutil pkg generate --hw-version 52 --bootloader-version 3 --bootloader secure_bootloader_uart_mbr_pca10056.hex --sd-req 0xCA --key-file private.key Secure_Bootloader_V3_package.zip

 

I am trying to do Bootloader DFU using below commands.

nrfutil dfu serial -pkg Secure_Bootloader_V3_package.zip -p COM8 -b 115200 -fc 0

 

But Bootloader DFU is not success. Below is the snapshot.

But I am able to do DFU of my application.

1) Is there any issue in generating boot-loader DFU package and loading.

2) As per below link I used version 3 as, already loaded bootloader version is 2. In bootloader code is there any version macro where I need to change to 3.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_bootloader_dfu_validation.html&anchor=lib_dfu_image

But above macro NRF_DFU_APP_DOWNGRADE_PREVENTION I am seeing “This does not apply the bootloader updates.” I am bit confused. Whether bootloader version should always be greater.

Thanks & Regards

Vishnu Beema

[Einar Thorsrud]

Hi Vishnu,

1. It looks good to me. Can you check the DFU image with "nrfutil pkg display <zip>"? What does it say? If that does not provide any hints, then  I wonder if you are testing on a DK or custom HW? If you are testing on a DK, then it could be good to disable the mass storage device feature of the onboard debugger as that could cause UART data corruption.

2. Yes, the version number should be increasing.

Einar

[beemavishnu]

Hi,

1) Please find snapshot "nrfutil pkg display"

2) Yes, I am trying on nRF Development kit. To disable mass storage do you mean "Disabling the Mass Storage Device functionality". Will cause any problem after disabling. Is there a way to enable Mass storage in future.

Thanks & Regards

Vishnu Beema

[Einar Thorsrud]

Hi Vishnu,

beemavishnu said:

1) Please find snapshot "nrfutil pkg display"

This shows a package withoug signature. Did you get this using the following command (from your initial question)?

nrfutil pkg generate --hw-version 52 --bootloader-version 3 --bootloader secure_bootloader_uart_mbr_pca10056.hex --sd-req 0xCA --key-file private.key Secure_Bootloader_V3_package.zip

The command looks OK, and when I copy-paste it and test I get a correctly signed DFU image. Can you double-check? If this command really did produce an unsigned image it would be interesting to know the exact nrfutil version you are using ("nrfutil version").

beemavishnu said:

2) Yes, I am trying on nRF Development kit. To disable mass storage do you mean "Disabling the Mass Storage Device functionality". Will cause any problem after disabling. Is there a way to enable Mass storage in future.

It is clear that there is an issue with your DFU package, so this is likely not related to the issue you are seeing. However, to answer your question you can re-enable the mass storage functionality using "MSDEnable".

Br,

Einar

[beemavishnu]

Hi,

Please find further details.

1) Yes, I used same command to generate bootloader package. You mentioned unsigned. Is this based on "signature_type: UNSIGNED" in snapshot ?

2) Below is the verion of nrfutil

3) I deleted existing package and regenerated. After that its shown as "signature_type: ECDSA_P256_SHA256" and able to do DFU of bootloader. But I am not sure why it was creating issue with previous package.

Thanks & Regards

Vishnu Beema

[Einar Thorsrud]

Hi Vishnu,

beemavishnu said:

1) Yes, I used same command to generate bootloader package. You mentioned unsigned. Is this based on "signature_type: UNSIGNED" in snapshot ?

Yes, that is what I mean. You will get this if you don't specify a key, by omitting the --key-file option. In this case, the DFU package can only be used with bootloaders that don't require signed updates. If you do, nrfutil also prints the following warning:

|===============================================================|
|##      ##    ###    ########  ##    ## #### ##    ##  ######  |
|##  ##  ##   ## ##   ##     ## ###   ##  ##  ###   ## ##    ## |
|##  ##  ##  ##   ##  ##     ## ####  ##  ##  ####  ## ##       |
|##  ##  ## ##     ## ########  ## ## ##  ##  ## ## ## ##   ####|
|##  ##  ## ######### ##   ##   ##  ####  ##  ##  #### ##    ## |
|##  ##  ## ##     ## ##    ##  ##   ###  ##  ##   ### ##    ## |
| ###  ###  ##     ## ##     ## ##    ## #### ##    ##  ######  |
|===============================================================|
|You are not providing a signature key, which means the DFU     |
|files will not be signed, and are vulnerable to tampering.     |
|This is only compatible with a signature-less bootloader and is|
|not suitable for production environments.                      |
|===============================================================|

I am not aware of any other way to generate DFU packages without a signature.

beemavishnu said:

2) Below is the verion of nrfutil

nrfutil version 5.2 should be OK. I have not found any references to issues with signing packages like this in that or other versions.

beemavishnu said:

3) I deleted existing package and regenerated. After that its shown as "signature_type: ECDSA_P256_SHA256" and able to do DFU of bootloader. But I am not sure why it was creating issue with previous package.

It is good that it works now. Could it be that you just forgot the --key-file option when you generated the package initially, and now you remembered it?

Br,

Einar