This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Buttonless ble dfu example not working in sdk v15.0.0

Hello,


I would like to use the bouttonless dfu feature in my application, but I have not been able to run the sdk example ble_app_buttonless_dfu.

The application does not work like the compiled example "ble_app_buttonless_dfu_without_bonds_s132_with_setting_page.hex" in the folder "examples \ dfu \ secure_dfu_test_images \ ble \ nrf52832", there is no advertising, the led does not flash. But if we press button 4 the bootloader starts.

Before trying the buttonless example, I tried with the bootloader compiled with my own dfu public key, then generated the setting page with my application and it works well.
So I think it's not a bootloader problem.

I use sdk v15.0.0 and compile with gcc (arm-none-eabi v7.2.1)

I use the NRF52-DK development platform.

As I have not managed to use the example ble_app_buttonless_dfu as it is, I find myself stuck in my project.

I also read the other topics related to the DFU BLE, but it is not the same version of sdk, or the same problem.

Can you help me find a solution?

Thank you very much,

Parents
  • Hi,

    The ble_app_buttonless_dfu_without_bonds_s132_with_setting_page.hex has been made from the exact same source code as the ble_app_buttonless_dfu example and secure_bootloader, so it should behave in the same way. Did you remember to generate and flash a valid setting page together with the application that you have compiled? You need to flash the following parts (separately or merged):

    • SoftDevice
    • Bootloader
    • Applicaton
    • Bootloader setting page
  • Hello sir,

    Indeed I flashed all these elements and generated the setting page in my previous tests, and I tried again today.

    So I have:

    Erase soc:

    => make erase

    flashed the softdevice:

    => make flash_softdevice

    flashed the bootloader:

    1: installed micro-ecc

    2: generated a private and public key

    3: replaced sfu_public_key.c

    4: make flash


    Compiled the application ble_app_buttonless_dfu

    => make


    Generate setting page:

    => nrfutil settings generate --family NRF52 --application ble_app_buttonless.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 bootloader_setting_page.hex


    Merge ble_app_buttonless.hex and bootloader_setting_page.hex:

    => mergehex --merge ble_app_buttonless.hex bootloader_setting_page.hex --output ble_app_buttonless_with_setting_page.hex


    And finaly flash and reset:

    => nrfjprog -f nrf52 --program ble_app_buttonless_with_setting_page.hex --sectorerase --reset

    I still have the same problem.

    I do not know what I could have forgotten.

  • I have not been able to reproduce the issue.

    Pressing button 4 during reset as you do forces the bootloader to stay in DFU mode instead of starting the application, so it is expected that you see that the bootloader is running in this case (with LED 1 and LED 2 lit). It would also stay in DFU mode if there was no valid application, so it seems that everything (including the bootloader settings page) is OK seen from the bootloader, and that it jumps to the application, but that something happens there.

    • Have you made any modifications in the example application?
    • Do you get the same behaviour if you use the _debug variant of the bootloader with the public key that is shipped with the SDK (you will not be able to sign the DFU image in this case and actually perform the DFU but it will be interesting to see if the behaviour is different).
    • Can you use a debugger to check the state of the device at the point where it should have started the application (after you have flashed the merged app settings / setting page hex and reset the device)? What is the value of the stack pointer?
    • Are you using the nRF52 DK or custom HW?
Reply
  • I have not been able to reproduce the issue.

    Pressing button 4 during reset as you do forces the bootloader to stay in DFU mode instead of starting the application, so it is expected that you see that the bootloader is running in this case (with LED 1 and LED 2 lit). It would also stay in DFU mode if there was no valid application, so it seems that everything (including the bootloader settings page) is OK seen from the bootloader, and that it jumps to the application, but that something happens there.

    • Have you made any modifications in the example application?
    • Do you get the same behaviour if you use the _debug variant of the bootloader with the public key that is shipped with the SDK (you will not be able to sign the DFU image in this case and actually perform the DFU but it will be interesting to see if the behaviour is different).
    • Can you use a debugger to check the state of the device at the point where it should have started the application (after you have flashed the merged app settings / setting page hex and reset the device)? What is the value of the stack pointer?
    • Are you using the nRF52 DK or custom HW?
Children
No Data
Related