DFU update issues when RPA is enabled

When performing a OTA update with RPA enabled, the dedicated DFU app, nrfconnect app, and nrfutil.exe fail because after the buttonless bootloading has been enabled the device's MAC address changes to the static MAC address of the device + 1 and the applications are unable to handle this situation.

To work around this, the DFU update must be cancelled/time out and then after searching again you can connect to "DfuTarg" and complete the DFU process.

Is it possible to start the nrf bootloader by sending data to the DFU characteristic directly? 

Parents
  • Hi,

    The nRF5 SDK bootlaoder does not have any supprot for privacy, so this is fundamentally how it is. One option is to use bond sharing (controlled by NRF_DFU_BLE_REQUIRES_BONDS in sdk_config.h). This introduces a few other issues though, so I would not necessarily recommend it.

    Another option could be to rely on setting the advertising name, and using that to reconnec to the device. This is supported in the buttonless DFU service, and the configured name is then used by the bootloader when it starts, and the peer device can filter on that (this is normally used with iOS, as iOS does not give the mobile application access to the BT address, so another method is needed to identify the device after it enters DFU mode with a different address).

    Is it possible to start the nrf bootloader by sending data to the DFU characteristic directly? 

    If you mean the DFU transport service that the bootloader itself exposes then no, that service only exists in the bootloader. If you mean the Buttonless DFU characteristic then that is the standard mechanism (and what nrfutil/nRF Connect/the app already use) to trigger the reset into DFU mode. You can implement your own trigger the same way if you want and refer to components/ble/ble_services/ble_dfu/ble_dfu.c as a reference.

    (Note that the part with incrementing the address must be kept, as without it, you will see problems with peer devices not performing service discovery when swithing between application and bootloader. The exception is if you bond and share bond with the bootloader, as in that case the service changed mechanism can be used to trigger service discovery. But again, this introduces some other problems and I would not recommend it.)

Reply
  • Hi,

    The nRF5 SDK bootlaoder does not have any supprot for privacy, so this is fundamentally how it is. One option is to use bond sharing (controlled by NRF_DFU_BLE_REQUIRES_BONDS in sdk_config.h). This introduces a few other issues though, so I would not necessarily recommend it.

    Another option could be to rely on setting the advertising name, and using that to reconnec to the device. This is supported in the buttonless DFU service, and the configured name is then used by the bootloader when it starts, and the peer device can filter on that (this is normally used with iOS, as iOS does not give the mobile application access to the BT address, so another method is needed to identify the device after it enters DFU mode with a different address).

    Is it possible to start the nrf bootloader by sending data to the DFU characteristic directly? 

    If you mean the DFU transport service that the bootloader itself exposes then no, that service only exists in the bootloader. If you mean the Buttonless DFU characteristic then that is the standard mechanism (and what nrfutil/nRF Connect/the app already use) to trigger the reset into DFU mode. You can implement your own trigger the same way if you want and refer to components/ble/ble_services/ble_dfu/ble_dfu.c as a reference.

    (Note that the part with incrementing the address must be kept, as without it, you will see problems with peer devices not performing service discovery when swithing between application and bootloader. The exception is if you bond and share bond with the bootloader, as in that case the service changed mechanism can be used to trigger service discovery. But again, this introduces some other problems and I would not recommend it.)

Children
No Data
Related