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, 

    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

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

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

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