How does experimental_ble_app_buttonless_dfu actually work??

RE: How does experimental_ble_app_buttonless_dfu actually work??

bjorn-spockeli — Mon, 25 May 2020 06:05:37 GMT

Happy to help! 🙂

RE: How does experimental_ble_app_buttonless_dfu actually work??

davege — Sun, 24 May 2020 18:11:54 GMT

Thanks a lot for your answer Bjørn!

RE: How does experimental_ble_app_buttonless_dfu actually work??

bjorn-spockeli — Fri, 22 May 2020 07:19:00 GMT

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

RE: How does experimental_ble_app_buttonless_dfu actually work??

davege — Thu, 21 May 2020 18:23:25 GMT

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.

RE: How does experimental_ble_app_buttonless_dfu actually work??

bjorn-spockeli — Mon, 16 Jan 2017 13:55:36 GMT

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