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

[kristofbo]

Hi,

Thank you for your answer.
I've performed the upgrade test but unfortunately it failed...

Scenario:
1. Flash bootloader and application
2. Perform bootloader DFU
3. Perform application DFU

Above scenario works fine but only when all software components comes from the same SDK version, i.e. all from SDK 2.0 or all from SDK 4.1.
However it does not work when upgrading from SDK 2.0 to SDK 4.1 like in below scenario:
1. Flash bootloader and application based on SDK 2.0
2. Perform bootloader DFU based on SDK 4.1
3. Perform application DFU based on SDK 4.1

In step 2. bootloader has been flashed and started successfully - which was indicated by LED3 being lit up, when bootloader started.
In step 3. the application has been downloaded and reset after DFU was performed, however the application was not activated by bootloader for some reason, and old application was started (the new application should lit up LED2, but it was not there is in this case).

Below you can see all instructions which you can just copy-paste it in order to reproduce this issue.

1. Download SDK 2.0 and 4.1 a extract them in corresponding folders (e.g. sdk-2.0 and sdk-4.1).
2. Go to SDK 2.0 DFU folder
   

   cd <your-path>/sdk-2.0
   cd examples/thread/dfu

3. Create cryptographic keys
   

   nrfutil keys generate priv.pem
   nrfutil keys display --key pk --format code priv.pem --out_file dfu_public_key.c
   cp dfu_public_key.c ../../dfu/

4. Install micro-ecc
   

   pushd ../../../external/micro-ecc
   git clone https://github.com/kmackay/micro-ecc
   pushd nrf52hf_armgcc/armgcc
   make
   popd
   popd

5. Build bootloader
   

   make -C bootloader/pca10056/blank/armgcc

6. Prepare the DFU Client
   

   sed -i.backup 's/#define BACKGROUND_DFU_CONFIG_LOG_LEVEL 3/#define BACKGROUND_DFU_CONFIG_LOG_LEVEL 4/g' client/pca10056/blank/config/sdk_config.h
   make -C client/pca10056/blank/armgcc
   nrfutil settings generate --family NRF52840 --application client/pca10056/blank/armgcc/_build/nrf52840_xxaa.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 settings.hex
   mergehex -m client/pca10056/blank/armgcc/_build/nrf52840_xxaa.hex settings.hex -o dfu_client.hex

7. Flash
   

   nrfjprog -f nrf52 --eraseall
   nrfjprog -f nrf52 -r --program ../../../components/softdevice/mbr/nrf52840/hex/mbr_nrf52_2.3.0_mbr.hex --chiperase
   nrfjprog -f nrf52 -r --program bootloader/pca10056/blank/armgcc/_build/nrf52840_xxaa_mbr.hex --sectoranduicrerase
   nrfjprog -f nrf52 -r --program dfu_client.hex --sectorerase

8. Go to SDK 4.1 DFU folder
   

   cd <your-path>/sdk-4.1
   cd examples/thread/dfu

9. Copy cryptographic keys created in SDK 2.0
   

   cp ../../../../sdk-2.0/examples/thread/dfu/dfu_public_key.c ../../dfu/
   cp ../../../../sdk-2.0/examples/thread/dfu/priv.pem .

10. Install micro-ecc
    

    pushd ../../../external/micro-ecc
    git clone https://github.com/kmackay/micro-ecc
    pushd nrf52hf_armgcc/armgcc
    make
    popd
    popd

11. Prepare app firmware package
    

    sed -i.backup 's/thread_bsp_init();/thread_bsp_init(); LEDS_ON(BSP_LED_1_MASK);/g' client/main.c
    make -C client/pca10056/blank/armgcc
    nrfutil pkg generate --hw-version 52 --sd-req 0x00 --application-version 2 --application client/pca10056/blank/armgcc/_build/nrf52840_xxaa.hex --key-file priv.pem app_dfu_package.zip

12. Prepare bootloader firmware package
    

    sed -i.backup 's/leds_init();/leds_init(); LEDS_ON(BSP_LED_3_MASK);/g' bootloader/main.c
    sed -i.backup 's/#define NRF_BL_DFU_ENTER_METHOD_BUTTON 0/#define NRF_BL_DFU_ENTER_METHOD_BUTTON 1/g' bootloader/pca10056/blank/config/sdk_config.h
    make -C bootloader/pca10056/blank/armgcc
    nrfutil pkg generate --hw-version 52 --sd-req 0x00 --bootloader-version 2 --bootloader bootloader/pca10056/blank/armgcc/_build/nrf52840_xxaa_mbr.hex --key-file priv.pem bl_dfu_package.zip

13. Perform bootloader DFU
14. Perform application DFU

I can send you logs from the whole process if you want.

Could you please check if this scenario is working for you? This is important for us, since it blocks us from upgrading to SDK 4.1.

Could you also tell if it's possible to downgrade bootloader and application from SDK 4.1 to SDK 2.0?

Best regards,
Krzysztof

[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