RE: Re-Bonding Issue with Phone after DFU

Einar Thorsrud — Wed, 17 Nov 2021 16:51:21 GMT

Hi,

I am not sure what the specific issue is here, perhaps you can elaborate? Until then, but combining "Re-Bonding Issue with Phone after DFU" with "If this is run using the nRF52840 Dongle and the nRF Desktop tools I can run the DFU multiple times" I interpret this to perhaps be an issue that you can do DFU multiple times with nRF Connect fro desktop as DFU master, but not a phone? If that is the case, then it is important to note that all modern phone OSs / BT stacks prevent automatic repairing. If the nRF and phone has bonded, and the bonding information is lost on the nRF, the user must delete the bond on the phone manually before they can bond again.

Bonds can be lost on the nRF for several reasons:

Deliberately deleted in some way
Inadvertently deleted, for instance because of:
- A full chip erase which (deleted the FDS pages where the peer manager stores bonding information)
- A DFU operation using a bootloader which is incorrectly configured with regards to the number of FDS pages used in the application. The NRF_DFU_APP_DATA_AREA_SIZE define in the bootloader's sdk_config.h must be adjusted to match the number of FDS pages used by the applicaiton. If this is too small, FDS pages may be overwritten during a DFU operation, causing data loss including bonding data.

[quote user=""]Which of these are needed?[/quote]

This depends a bit on your app. What you typically would use of what you list is pm_handler_secure_on_connection() should normally be called in your BLE event handler for all events. pm_handler_disconnect_on_sec_failure() is normally called for alle vents in the applications peer manager event handler. I suggest you refer to a example application to see examples, and API doc for details. Other things like

[quote user=""]By adding the case statement it appears to work, but are there things i am missing?[/quote]

These are functions that provide various features you may or may not want (automatically try to secure link on connection, automatically disconnect on insufficient security, etc. Whatever is the "correct" approach here is application specific.