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,

Have you made sure that the flash is erased before you try to program it? If it is not, that could explain the mismatch. Try adding "--recover" to the nrfjprog command you use, or do an "nrfjprog --recover" separately before this step.

[AndrewJKnowles]

Hi Einar,

Ive successfully programmed the development board using:

However, when i power cycle the board. All LEDs are solidly illuminated which according to this table:

indicates that either BSP_INDICATE_FATAL_ERROR or BSP_INDICATE_USER_STATE_3 or BSP_INDICATE_USER_STATE_ON. When using the mobile app nRF Toolbox, the device name "Nordic_Buttonless'" cannot be seen so i think it may be a fatal error. I have tried this on two different BL654 dev boards, both respond with the same led behaviour.

Running the command again with --log provides the following log file.

7585.log.log

[Einar Thorsrud]

Hi,

Yes, that indicate a fatal error. Have you checked which error occured? One way to find out is to make a debug build (define DEBUG for the project) and enable logging, and observe the log output. Then you should see the file name and line number and error code. Alternatively, check with a debugger (then you should also disable optimization).

[AndrewJKnowles]

Hi, 

Apologies for the delayed response, Ive been out of office. This has been resolved due to a hardware issue. Whe have current generated a bootloader with settings and an active softdevice. However, the boot loader will not execute the app (after power up). The app in this case is the simple peripheral blinky example.

Using NRF Connect programmer i can see that the structure of the device is correct however on debugging the bootloader in keil, the boot loader returns "ACTIVATION_NONE" in nrf_bootloader_fw_activate (nrf_bootloader_fw_activation.c) after calling p_bank->bank_code

would you have any suggestions?

Thanks

[AndrewJKnowles]

Additionally i have found that nrf_dfu_validation_boot_validate calls a hardfault from line 971

uint32_t crc = crc32_compute(p_data, data_len, NULL);

despite having a valid CRC

[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.