• State Verified Answer
  • Replies 5 replies
  • Subscribers 73 subscribers
  • Views 2654 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 118962
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How does experimental_ble_app_buttonless_dfu actually work??

Dave_couling

I'm been analyzing this code for a while now but can't see how this code actually triggers a switch into the Bootloader mode. There are no references to any resets or the initial entry points to actually starting the DFU process. Can someone please explain to me how this Application w/ DFU actually works? Thanks

-DC

Parents
  • 0

    Hi Dave,

    quote from the Experimental: Buttonless DFU Template Application description on Infocenter

    When notification of DFU control point characteristic is enabled, and the value 0x01 is written to it, the device will disconnect, send the event BLE_DFU_EVT_ENTERING_BOOTLOADER, and enter the bootloader.

    So how is this done in the code?

    Once you have enabled notification of the DFU Control Point characteristic and written 0x01 to the characteristic, the device will enter on_ctrlpt_write() in ble_dfu.c. on_ctrlpt_write() will in turn call enter_bootloader() which writes the enter_buttonless_dfu flag in the bootloader settings flash page to true. When the flash write is complete the device will enter the flash_callback which calls sd_ble_gap_disconnect. When the device has successfully disconnected you will get the BLE_GAP_EVT_DISCONNECTED event which is propagated to ble_dfu_on_ble_evt which in turn will call on_disconnect() in ble_dfu.c which calls NVIC_SystemReset();

    The device will then reset and execution will start in the bootloader, which checks if the enter_buttonless_dfu flag is set to true. If it is, then the device will enter bootloader mode.

    Best regards

    Bjørn

  • 0 in reply to bjorn-spockeli

    Hi Everyone.


    As far as I can see, the execution flow presented by @bjorn-spockeli is no more holding true for nRF5 SDK 16.0.0.

    The function enter_bootloader() is not writing the enter_buttonless_dfu variable.
    What I see instead is that (for both bonded and unbonded version of the BLE DFU service) at some point there is a call to ble_dfu_buttonless_bootloader_start_finalize which is setting GPREGRET register.

    That means that DFU still can work (i.e. transitioning to DFU mode), since register is checked at boot from nrf_bootloader.

    But now I don't see any usefulness to enter_buttonless_dfu variable stored in MBR settings.

    Can someone explain this better? Why did the code had this evolution over time?

    Thanks.


    D

  • 0 in reply to davege

    Hi Davege, 

    You are correct that the SDK v16.0.0 DFU solution does not use the bootloader settings to signal the bootloader that it should stay in bootloader mode and not jump to the application. 

    Instead the GPREGRET register is used, which was the approach used in our legacy DFU solution( SDK v11 or older). There were a couple of SDK versions ( SDK v12.0.0 to SDK v12.2.0) where we were looking at alternative notification mechanisms and the Experimental implementation in SDK v12 is a result of that. 

    In the end we ended up choosing the same notification mechanism as we used previously, i.e. use the GPREGRET register,  as the experimental versions that used the bootloader settings for this had some drawbacks. 

    Best regards

    Bjørn

Reply Children
No Data
Related
Terms of service