BLE Secure DFU Bootloader with nRF52832 Project Build Errors

Hi,

I'm following this "Getting started with Nordic's Secure DFU bootloader, a step by step guide" (https://devzone.nordicsemi.com/guides/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader#h75sjziavjbukzaywg6xlx19np0fm4) and using the nRF5_SDK_17.1.0_ddde560\examples\dfu\secure_bootloader project. However, when I built it (at step B3 in that guide), it gave me these errors.

How may I solve them? Or are there any other example projects or guides that I can follow to program nRF52832 through BLE? I've also tried the ble_app_buttonless_dfu, and that project could be built (no errors) but the nRF52832 didn't BLE advertise after firmware loading. 

Thanks,

Han

Parents
  • Hello Han,

    Did you move the application project file before trying to build, or is it still located in SDK\examples\dfu\secure_bootloader\pca10040_s132_ble\ses\ ?

    If you did move it, does it build if you try to build it in the original location?

    If you did not move it, can you please try to shorten the path? rename nRF5_SDK_17.1.0_ddde560/nRF5_SDK17.1.0ddde560\ to "17.1.0" by creating a folder called "17.1.0", and placing everything in the SDK inside there. (I also notice that you have two folders inside one another named nRF5_SDK17.1.0_ddde560. You can try to reduce this to only one first.

    If nothing works, is there a reference to nrf_section_iter_next in your SDK? It should be in SDK\components\libraries\experimental_section_vars\nrf_section_iter.c. Is that file included in your bootloader SES project? And is "NRF_SECTION_ITER_ENABLED" defined to "1" in your bootloader's sdk_config.h?

    Best regards,

    Edvin

  • I am now having trouble of sending the DFU package when it's larger than 60kB. When loading the DFU package through nRF Connect app, the graph just shows disconnecting (not showing percentage) and then escape without loading the file onto the device. How may I fix this?

    Additionally, when I tried to load the DFU package (with the project hex file is from the ble_app_buttonless_dfu example), the package was loaded successfully through DFU. However, the BLE didn't advertise afterwards (cannot find Nordic_Buttonless when doing BLE scan). I have also tried loading the ble_app_buttonless_dfu directly through Segger and it didn't BLE advertise either. Does it mean something is wrong with the example ble_app_buttonless_dfu code? The blinky and uart examples worked fine.

  • Hello,

    HanCatNguyen said:
    The blinky and uart examples worked fine

    What does that mean, exactly? Did you build these applications yourself, and transfer them via DFU? Or are these some sample application images that you transferred over DFU?

    When testing applications like this, I find it useful to program them manually first, to make sure that the combination with Bootloader, SoftDevice, Application and Bootloader Settings* work as intended. 

    * The bootloader settings must be generated and programmed together with the application .hex file. Every time you re-build your application, you need to update this bootloader settings file, because it holds the signature and CRC check of the application. Without it, the bootloader will reject the application, and remain in DFU mode. 

    I prefer to use a script for this (.bat file or .sh file, depening on your OS). The script will copy the .hex file from the bootloader and application, and generate the bootloader settings file (using "nrfutil settings generate ..." See nrfutil settings generate --help), and then program all the 4 hex files using nrfjprog. Bootloader, application, softdevice and bootloader settings.

    Try this using the image that didn't start advertising. Try enabling logging in your application. Is the application's main() function reached? 

    You can also try to run a debug session, but in that case, please use the "Target" -> "Attach debugger" option:

    Because if you start a debug session like you normally would, a slightly different .hex file is uploaded, and it will be rejected by the bootloader. 

    Best regards,

    Edvin

  • I did generate the package according to the Getting started with Nordic's Secure DFU bootloader, a step by step guide tutorial for s112: nrfutil pkg generate --hw-version 52 --application-version 1 --application ble_app_buttonless_dfu_pca10040e_s112.hex --sd-req 0x103 --key-file private.key app_dfu_buttonless_s112_package.zip. I could flash it through DFU, but the board doesn't advertise afterwards (couldn't find Nordic_Buttonless when doing BLE scan).

    I already could flash my custom firmware through DFU with the secure_bootloader (the bootloader works fine with normal application), but I want to be able to flash it buttonless. I wanted to try the ble_app_buttonless_dfu example to flash DFU OTA buttonless, but that example code isn't working.

    2 ways that I've tried, but none of them work:

    1. Flash the softdevice (s112) -> secure_bootloader -> Flash ble_app_buttonless_dfu package through DFU -> Flashed sucessfully but no advertising afterwards (cannot find Nordic_Buttonless or DfuTarg in BLE scan).
    2. Flash the ble_app_buttonless_dfu directly in Segger (so with softdevice s112) through J-link -> Error at ble_dfu_buttonless_async_svci_init().
    3. Flash the softdevice (s112) -> secure_bootloader -> Flash the ble_app_buttonless_dfu hex file through J-Link -> Still see in BLE scan as DfuTarg, not Nordic_Buttonless. 

    Am I flashing the firmware for buttonless DFU wrongly? Or is there a specific tutorial/document/example code that shows exactly what needs to be changed in my custom firmware to be able to do buttonless DFU with the SDK 17.1.0?

    Thanks,

    Han

  • Hello,

    HanCatNguyen said:
    Flash the softdevice (s112) -> secure_bootloader -> Flash ble_app_buttonless_dfu package through DFU -> Flashed sucessfully but no advertising afterwards (cannot find Nordic_Buttonless or DfuTarg in BLE scan).

    This suggests the application (ble_app_buttonless_dfu) starts, but fails before it starts advertising -> resets, starts again, but fails before it starts advertising.

    HanCatNguyen said:
    Flash the ble_app_buttonless_dfu directly in Segger (so with softdevice s112) through J-link -> Error at ble_dfu_buttonless_async_svci_init().

    Yes, that is because no bootloader is present, so ble_dfu_buttonless_async_svci_init() will fail.

    HanCatNguyen said:
    Flash the softdevice (s112) -> secure_bootloader -> Flash the ble_app_buttonless_dfu hex file through J-Link -> Still see in BLE scan as DfuTarg, not Nordic_Buttonless. 

    Yes. This is because when you flash it with the programmer, no bootloader settings will be generated by the bootloader, like it will be when you perform the DFU, like you did in 1). Therefore, the application will be rejected, and it will remain in DfuTarg mode. 

    So what you need to do is what I tried to explain in the previous reply. Either, perform the DFU, flash the ble_app_buttonless_dfu directly using the debugger/programmer. If you program it with the programmer, you need to manually generate the bootloader settings and program that .hex file as well. 

    Alternatively, do what you did in 1), and then "attach debugger", like I showed in the screenshot in the previous reply, and use this debug session to figure out why it doesn't start advertising. Does the log say anything?

    Best regards,

    Edvin

Reply
  • Hello,

    HanCatNguyen said:
    Flash the softdevice (s112) -> secure_bootloader -> Flash ble_app_buttonless_dfu package through DFU -> Flashed sucessfully but no advertising afterwards (cannot find Nordic_Buttonless or DfuTarg in BLE scan).

    This suggests the application (ble_app_buttonless_dfu) starts, but fails before it starts advertising -> resets, starts again, but fails before it starts advertising.

    HanCatNguyen said:
    Flash the ble_app_buttonless_dfu directly in Segger (so with softdevice s112) through J-link -> Error at ble_dfu_buttonless_async_svci_init().

    Yes, that is because no bootloader is present, so ble_dfu_buttonless_async_svci_init() will fail.

    HanCatNguyen said:
    Flash the softdevice (s112) -> secure_bootloader -> Flash the ble_app_buttonless_dfu hex file through J-Link -> Still see in BLE scan as DfuTarg, not Nordic_Buttonless. 

    Yes. This is because when you flash it with the programmer, no bootloader settings will be generated by the bootloader, like it will be when you perform the DFU, like you did in 1). Therefore, the application will be rejected, and it will remain in DfuTarg mode. 

    So what you need to do is what I tried to explain in the previous reply. Either, perform the DFU, flash the ble_app_buttonless_dfu directly using the debugger/programmer. If you program it with the programmer, you need to manually generate the bootloader settings and program that .hex file as well. 

    Alternatively, do what you did in 1), and then "attach debugger", like I showed in the screenshot in the previous reply, and use this debug session to figure out why it doesn't start advertising. Does the log say anything?

    Best regards,

    Edvin

Children
No Data
Related