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]

Yes, enabling NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS in sdk_config.h in both the application and bootloader is all that is needed for bond sharing. 

The application will then call nrf_dfu_set_peer_data() prior to resetting to the bootloader. 

Bjørn

[AntonHellbe]

I've got the build working now.

However when I try to initialize the async SVC interface it fails with error code 8 (NRF_INVALID_STATE).

<info> app: Initialized GATT
<info> app: Initialized services.
<info> app: Setting vector table to bootloader: 0x00072000
<info> app: Setting vector table to main app: 0x00026000
*Reboot*

Edit: With DEBUG enabled:

<info> app: Initialized GATT
<info> app: Setting vector table to bootloader: 0x00072000
<debug> app: nrf_dfu_svci_vector_table_set() -> success
<debug> app: nrf_dfu_set_peer_data_init() -> success
<info> app: Setting vector table to main app: 0x00026000
<debug> app: nrf_dfu_svci_vector_table_unset() -> success

[bjorn-spockeli]

The log line

Setting vector table to main app: 0x00026000

indicates that ble_dfu_buttonless_async_svci_init has returned, but it could be that it returned a non-zero error code and that it was caught by APP_ERROR_CHECK(err_code). 

Can you compile the application in the debug configuration(add DEBUG to the preprocessor definintions) and then set a breakpoint in app_error_fault_handler()? 

-Bjørn

[AntonHellbe]

Updated my answer with the error code it's giving me, I missed the APP_ERROR_CHECK.

[AntonHellbe]

Ok so It's not the async SVC interface that's giving me NRF_INVALID_STATE, it's when I try to initialize the service.