What is the expected success rate of a DFU update?

We have both native iOS and Android-apps that handle DFU-updates of our BLE-FW on our HW-devices. We are currently experiencing a dip in success rate (according to our firebase metrics) on Android, where we seem to get an increased number of "GATT ERROR" during updates (no further information is available).

On Android we used to have a success rate of above 95%, and now we're down to 66% for no apparent reason (i.e. no changes to the app code handling the update, only the binary file has changed). iOS seems to succeed better, and stays around 90-95% as before.

Is there some form of "suspected success rate" on Android and on iOS (particularly interesting on Android due to the vastness of HW variants) for this chip that we can use as a "baseline" for what can be expected?

  • As far as I can tell, the logic is implemented more or less verbatim of how it is described here:

  • Hi,

    What phone did you use? Do you see the same if you test with other phones?

  •  The phone was a Pixel 4a, and this is the device that has been "most reliable" among our testing devices to reproduce the issues. Other devices seem to work every time, some fail intermittently.

  • Hi,

    Hijacking this thread to add information about the issue, I'm working close with the thread creator on the embedded side.

    We are using a Laird module BL652-SA with nRF52832.

    Most phones can handle the DFU upgrade flow from Android. We can re-create the issue right now on a Google pixel 4. But the issue is reproducible on several other brands eg. Samsung Galaxy S10.
    The issue does not always appear. The upgrade flow can sometimes fail sometimes succeed. if the DFU upgrade is successful  the paring information on the phone is always removed after completed DFU upgrade. The nRF chip is upgraded with new firmware and has still the bonding information.
    So the issue seems to be from the Phone application side.
    If we are using nRF Connect debug application and trying DFU upgrade from the debug application the Upgrade always works as expected.

    The issue never appears on iPhone. Our iPhone application is not using the NRF DFU SDK but our Android application is using the nRF DFU SDK. We are using the DFU buttonless feature to set the device to DFU mode.

    If I scan for Bluetooth devices while upgrading i can see the unit changing from our normal advertising name ABCD_[s/n] to HDFU_[s/n] which is set by our bootloader when we set it to DFU upgrade state. So the device is restarted and set as expected.

    To mention is:
    I can find two devices with the same MAC when I scan. One with the name (unknown) and one with our desired name.
    The same happens when the device is in DFU mode.

    We set the device name with: sd_ble_gap_device_name_set

    I can't figure out where the (unknown) UUID is coming from. I have an idea that the DFU gets confused and mixup the two when trying to upgrade, but its a long shot.

    Relating the thread issue to my text.

    The gatt error seems to come after upgrading from our application on Android because the paring information has been lost.

    Do you have any ideas how to proceed with the debugging or any known bugs from the nRF DFU SDK or if our (unknown) UUID can affect in any way.

    Thanks for your help

  • the paring information on the phone is always removed after completed DFU upgrade. The nRF chip is upgraded with new firmware and has still the bonding information.

    Have you tried this: https://github.com/NordicSemiconductor/Android-DFU-Library/blob/913dbc128095b211e85e476fb10d497379e9be33/lib_dfu/src/main/java/no/nordicsemi/android/dfu/DfuServiceInitiator.java#L175 and setting to true?

    By default it will remove bond info, as this feature was added later in the SDK.