Questions regarding DFU, Bonding and iOS (caching)

[AntonHellbe]

Hi,

I have some questions regarding DFU, Bonding and iOS (caching). In my current project I have a DFU bootloader which does not use bonds, however the application uses bonds.

The current setup is that the DFU bootloader uses a different MAC-address than the application, this way iOS will treat the DFU bootloader and the application as two different devices and caching is not an issue. Is this an okay solution or would it be preferable to use bonds in the DFU FW since the application uses it?

If using bonds with the DFU and adding the Services Changed characteristic and the application is it possible to share the bonding information between Application and DFU FWs? Is there any example that uses bonds for both DFU and application? From what I've read the DFU FW does not know where the App stores the bonding information and vice versa.

I've have tried changing the DFU FW to also use bonds, however I run into issues when I try to mergehex the settings file for the application with the hex for SD + APP + Bootloader, I'm assuming this is because there are overlapping memory addresses.

HW: nRF52832

SDK: 15.0

Softdevice: 6.0

Br,
Anton

[bjorn-spockeli]

The current setup is that the DFU bootloader uses a different MAC-address than the application, this way iOS will treat the DFU bootloader and the application as two different devices and caching is not an issue. Is this an okay solution or would it be preferable to use bonds in the DFU FW since the application uses it?

The Secure bootloader in our SDK is considered production code so we do consider it a 'OK' solution for our customers. 

If you configure the bootloader to use bonds, then the bootloader will only allow bonded devices to write to the DFU Control Point and DFU Packet characteristics. The same thing applies to the Buttonless DFU service characteritics in the application, only bonded peers will able to put the nRF device in bootloader mode. The BLE link that the DFU is performed over will also be encrypted. 

If the bootloader and the Buttonless DFU service does not require bonds, then any central device can put the nRF in bootloader mode and write to the DFU Control Point and DFU Packet characteristics. The BLE link that the DFU is performed over will in this case not be encrypted. 

Note that a DFU package will only be accepted if BLE central has an DFU image that has been signed with the private key that the public key was derived from in the bootloader on the nRF Device. Any other image will be rejected. 

 

If using bonds with the DFU and adding the Services Changed characteristic and the application is it possible to share the bonding information between Application and DFU FWs? Is there any example that uses bonds for both DFU and application? From what I've read the DFU FW does not know where the App stores the bonding information and vice versa.

 Yes, it is possible for the application to share the bonding information with the bootloader. This is done when you definine NRF_DFU_BLE_REQUIRES_BONDS in the sdk_config.h file in the bootloader and defining NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS  in the sdk_config.h file of the application.

The application will then use the function nrf_dfu_set_peer_data(), which is defined in the bootloader through a async SVC interface, to share the bonding data with the peer. When the device restes to bootloader mode, it will then use that bonding information to re-establish and re-encrypt the connection 

I've have tried changing the DFU FW to also use bonds, however I run into issues when I try to mergehex the settings file for the application with the hex for SD + APP + Bootloader, I'm assuming this is because there are overlapping memory addresses.

 It should only be a matter of defining NRF_DFU_BLE_REQUIRES_BONDS in the sdk_config.h file in the bootloader and defining NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS  in the sdk_config.h file of the application.  The settings hex should only contain data on the bootloader settings page. You can also write it to the nRF device with nrfjprog using the --sectorerase option after flashing the bootloader. 

Best regards

Bjørn

[AntonHellbe]

The application will then use the function nrf_dfu_set_peer_data(), which is defined in the bootloader through a async SVC interface, to share the bonding data with the peer. When the device restes to bootloader mode, it will then use that bonding information to re-establish and re-encrypt the connection

Where can I read more about nrf_dfu_set_peer_data()? I've tried looking through the Infocenter but the closest relevant information I can find is this.

It should only be a matter of defining NRF_DFU_BLE_REQUIRES_BONDS in the sdk_config.h file in the bootloader and defining NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS  in the sdk_config.h file of the application.  The settings hex should only contain data on the bootloader settings page. You can also write it to the nRF device with nrfjprog using the --sectorerase option after flashing the bootloader. 

I'm no quite sure how to ensure that the settings hex only contains data on the bootloader settings page. I've followed the steps that you provided in an answer to another user here on the dev zone. It fails on step 8 when I try to merge the settings file.

Note: Im also getting NRF_ERROR_INTERNAL if I just try to flash the bootloader.

[bjorn-spockeli]

AntonHellbe said:

Where can I read more about nrf_dfu_set_peer_data()? I've tried looking through the Infocenter but the closest relevant information I can find is this.

 The async SVC interface is not particularly well documented, so I would recommend that you take a look at the source code in the bootloader, i.e. 

nRF5_SDK_15.0.0_a53641a\components\libraries\bootloader\dfu\nrf_dfu_svci_handler.c

nRF5_SDK_15.0.0_a53641a\components\libraries\svc\nrf_svc_handler.c

nRF5_SDK_15.0.0_a53641a\components\libraries\bootloader\dfu\nrf_dfu_svci.c

the most relevant function is nrf_dfu_set_peer_data_on_call() in nrf_dfu_svci_handler.c. 

AntonHellbe said:

I'm no quite sure how to ensure that the settings hex only contains data on the bootloader settings page. I've followed the steps that you provided in an answer to another user here on the dev zone. It fails on step 8 when I try to merge the settings file.

 This is taken care of by nrfutil, but if you are using nRF5 SDK v15.0.0, then make sure that you use the --no-backup when generating the settings page. Otherwise the generated settings hex file will contain an extra backup page that was introduced in SDK v15.1.0 I believe.

Best regards

Bjørn

[AntonHellbe]

Thanks for the information. I will try it out today and get back to you.

[bjorn-spockeli]

Happy to help :) Let me know if you run into any issues.

-Bjørn