BLE Bootloader FDU Example Verification Error

[AndrewJKnowles]

Hi, 

I am looking into adding BLE OTA firmware update functionality and started by exploring the example provided in Nordic SDK (SDK v16.0.0) while following the documentation provided here.

I ensure that the BLE Secure DFU Bootloader (from examples\dfu\secure_bootloader\pca10056_s140_ble\arm5_no_packs) and the softdevice are programmed, before attempting to program the pre compiled dfu example hex file "sd_s140_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_without_bonds" via nrfjprog. After a successful programming stage, the verification fails with unexpected values in particular addresses (see below).  

I was wondering how to rectify this issue while using the precompiled hex files to demonstrate FDU as proof of concept.

I am currently using:

• SDK v16.0.0 (though v17.1.0 sees to share the same issue)
• nRF52 Development board (DVK-BL654)
• CMD Prompt tools:
  • 
• J-Link version 11.0.16.1

Please also find the attached hex and log files.

sd_s140_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_without_bonds.hex0207.log.log

Thank you.

[Einar Thorsrud]

Hi,

If a hardfault is caused by the call to crc32_compute(), that is likely because p_data is invalid (or somwere after p_data wihin the length specified by data_len), causing an invalid memory access. That should not happen, though. Which changes have you made to the example bootloader?

If you don't make progress, can you test with the example debug  bootloader (suffixed _debug) that has RTT logging, and share the RTT log here along with a detailed description of the firmware you are using, how you programmed and how you are testing?

[AndrewJKnowles]

Hi, 

I will reply with more detail once i have completed more testing. In the meantime, could I ask for some advice about adding the bootloader too an existing app? I believe that the process (Using nRF52840 softdevice v7.0.1) is as follows: 

1. Generate bootloader settings from bootloader.hex using 
    nrfutil settings generate --family NRF52840 --application Bootloader.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 --softdevice softdevice.hex --sd-boot-validation VALIDATE_GENERATED_CRC --app-boot-validation VALIDATE_GENERATED_CRC Bootloader_Settings.hex
2. Merge bootloader.hex, bootloader_settings.hex, Application.hex
3. program merged hex file to device and reset

However this process doesnt seem to load the application upon reset? See attached combined hex and memory usage:

New_App.hex

[Einar Thorsrud]

Hi,

The approach you describe is mostly correct (though you also need to merge with the SoftDevice if that is used). However, there is one important error. You point to the bootloader hex file when you generate the setting page, but you should provide the application hex file.

[AndrewJKnowles]

Ah thank you for pointing that out, so the process should be:

1. Generate bootloader settings from bootloader.hex using 
    nrfutil settings generate --family NRF52840 --application Application.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 --softdevice softdevice.hex --sd-boot-validation VALIDATE_GENERATED_CRC --app-boot-validation VALIDATE_GENERATED_CRC App_Settings.hex
2. Merge bootloader.hex, App_settings.hex, Application.hex, Softdevice.hex
3. program merged hex file to device and reset

With regards to running the debug example. I flashed the example "secure_bootloader_ble_s140_pca10056" (SDK 16.0.0) to the development board. The device appears within my mobile ble scanner as "DfuTarg" and is connectable with a primary 0xFE59 service. However, following the processes in nrfutil_v6.1.0 (sections 4 and 5.1) to update the device using a secondary dev board nrfutil provide an error.

nrfutil_v6.1.0.pdf

0434.dfu_update.zip

[Einar Thorsrud]

Hi,

nrfutil has a probelm with connecting to the board running the connectivity firmware for some reason. To reduce the number of unknown, can you use nRF Connect for Dekstop Bluetooth intsead for now to test DFU? (nrfutil support for the old nRF5 SDK is archived and not maintained).