Re-Bonding Issue with Phone after DFU

[WesC]

Using nRF52832 and nRF52840

nRF5 SKD 17.1.0

I have bonding running, and have bonded initially (first run with bonding enabled), and Buttonless DFU upgraded once (using a .zip file). It won’t repeat.

I erase and program the entire flash with a .hex file containing the debug bootloader (merged with settings page), S132 SoftDevice, and application built from Debug configuration.

Also I have “program same version” enabled, “program older versions” enabled too – just to make dev and test easier.

If this is run using the nRF52840 Dongle and the nRF Desktop tools I can run the DFU multiple times.

I read nSDK Version 17.0.2 peer_manager_handler.h and peer_manager_handler.c and discovered that these files recommend FOUR additional function calls for bonding/LESC support that are NOT in the Buttonless DFU Template App.

pm_handler_disconnect_on_sec_failure()

pm_handler_disconnect_on_insufficient_sec()

pm_handler_secure_on_connection()

pm_handler_secure_on_error()

I also saw the recommendation for pm_event _handler to include 

case PM_EVT_CONN_SEC_CONFIG_REQ:

Which of these are needed?

By adding the case statement it appears to work, but are there things i am missing?

Because my primary interest is robustness – being bulletproof, what else can I do to make bonding can always work in a buttonless DFU environment?   

[Einar Thorsrud]

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.

Which of these are needed?

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 

By adding the case statement it appears to work, but are there things i am missing?

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.