BLE Bootloader FDU Example Verification Error

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.

Parents
  • 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.

  • 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

  • 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).

  • 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

  • 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

  • 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?

  • 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

Reply
  • 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

Children
  • 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.

  • 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

  • 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).

  • Hi

    the nRF connect desktop app generated an error when trying to set up the second device

    However, i downloaded the nRF DFU mobile app and was successfully able to preform an AOT DFU. I am not sure why my bootloader app isn't functioning properly. However judging by the simplicity of the bootloaders implementation, i cant see why the "secure_bootloader_ble_s140_pca10056" example wouldn't full fill our needs.

    Thank you.

  • Hi,

    I see. Good you got it working with the mobile for now. And good that the example seems to fullfill your needs. It is a quite generic bootloder, so that is what I expected as well. Most will typically use the example bootloader with few or no changes.

    If you want to use nrfutil or nRF Dekstop to perform DFU via a DK, it can be worth tryign to disable the mass storage device feature of the DK, as that often improves reliability. You can do that by opening J-Link Commander, and typing the MSDDisable command.

Related