Bootloader and SoftDevice update using Thread Secure DFU

[kristofbo]

nRF5 SDK for Thread and Zigbee v4.1.0 documentation states that only application can be updated over Thread Secure DFU.
However, nRF5 SDK for Thread and Zigbee v2.0.0 documentation says:
"Thread Secure DFU accepts images that contain a new bootloader or application, which contains the Thread network stack":

Does something changed in SDK 4.1 which is causing that bootloader can no longer be updated?
Is there any way to update bootloader and SoftDevice using Thread Secure DFU?

[Jørgen Holmefjord]

Hi,

Sorry for the slow response to this. I checked with our developers and they did not see any reasons that bootloader updates should not be possible over the Thread network.

I verified this by doing a bootloader update and check that the updates are received. I followed the instructions on this page, however in step 5, I did the following changes:

• Add the line "LEDS_ON(BSP_LED_3_MASK);" after "leds_init();" in main() function of Thread Secure Bootloader project.
• Modify sdk_config.h file of Thread Secure Bootloader project to set "#define NRF_BL_DFU_ENTER_METHOD_BUTTON 1".
• Generate DFU packet using following command:
  

  nrfutil pkg generate --hw-version 52 --sd-req 0x00 --bootloader-version 2 --bootloader bootloader\pca10056\blank\armgcc\_build\nrf52840_xxaa.hex --key-file priv.pem bl_dfu_package.zip

  
  

When the DFU is completed in step 7, hold Button 4 of the board while power cycling it. This will enter the bootloader, and you should observe that LED4 is lit up.

I will create an internal ticket for getting the documentation revised to avoid confusion.

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

I tested following your instructions, but I'm not able to update the bootloader/firmware correctly.

Will test more tomorrow with more debugging enabled, and will also compare the flash content to see what happens.

Best regards,
Jørgen

[kristofbo]

Hi,

Thank you for looking into this.
Please just let me know if you need some assistance with above setup.

Regards,
Krzysztof

[Jørgen Holmefjord]

Hi,

Sorry for the slow response on this. I have verified that the bootloader is updated correctly, but still struggling to determine why the newly received application is not activated.

I will continue to work on this the next few days, hoping to have an answer for you soon.

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

Sorry again for the slow response.

I think I have tracked down the problem to the change in bootloader settings that happened between nRF5 SDK v15.2.0 and v15.3.0. What happens is this:

• When updating the bootloader from Thread SDK v2.0.0 to v4.1.0, the new bootloader supports the new bootloader settings format. 
• After bootloader update, the bootloader detects the old settings format in flash and upgrades this to the new format.
• The Thread DFU client application still only supports the old bootloader settings format, since this is based on SDK 2.0.0.
• When the application transfer is completed, the old Thread DFU client will write the settings in the old format to flash. This is not detected by the bootloader, as it is not in the format it expects. The valid application in bank1 is therefore not detected.

I discussed this with one of my colleagues, and he suggest that in this case it would be required to first update a "middle application" that supports both settings formats. It will go something like this:

settings-version = read(bootloader_settings)

if (settings-version==1):
    write(old_settings_format)
else if (settings-version==1):
    write(new_settings_format)

I will try to implement something like this in the beginning of next week, to se if this resolves the issue.

Best regards,
Jørgen

[kristofbo]

Hi,

Thank you for the good news. Waiting for your results.

Best regards,
Krzysztof

[kristofbo]

Hi,

Do you have any update on this matter?

Best regards,
Krzysztof