DFU Library Error in Android but Not iOS --- Error 8 (0x8) GATT CONN TIMEOUT

[beeboopx]

This is not a duplicate of:

https://devzone.nordicsemi.com/question/87015/nrf-toolbox-gatt-conn-timeout-during-dfu/

https://devzone.nordicsemi.com/question/64206/getting-a-gatt-conn-timeout-message-when-trying-to-upload-a-new-firmware-via-ble-dfu/

https://devzone.nordicsemi.com/question/94972/error-8-0x8-gatt-conn-timeout-on-android/

I have tried to implement the accepted answers from these posts, but they did not work. Increasing the Max CI to 60, 100, or 500 do not work, nor does reducing the Android Packet Receipts Notification Procedure Number of Packets from 10 to 1, nor a combination of those two.

...

MCU: nRF52832

SoftDevice: SD132 v3.1.0

Phones: Samsung Galaxy S7 Edge on Android 7.0, Nexus 5 on Android 6.1, XiaoMi Mi A1 on Android 8.0

Nordic SDK: 12.2 with Secure Buttonless DFU

...

A) DFU with nRF Toolbox on iOS is good.

B) DFU with nRF Toolbox or nRF Connect on all tested Androids fail with "Error 8 (0x8) GATT CONN TIMEOUT"

The Android DFU Library successfully writes to the DFU Control Point, which writes to Bootloader Settings in Flash, resets the main application, and then the MCU launches the Bootloader in DFU Mode. Everything is the same between iOS and Android DFU until this point in the firmware logs:

Firmware Log from Successful iOS DFU

nrf_ble_dfu.c BLE_GAP_EVT_CONNECTED
Max CI = 24
Min CI = 24
Slave Latency = 0
Conn Sup TO = 72

nrf_ble_dfu.c BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST

nrf_ble_dfu.c BLE_GATTS_EVT_WRITE

nrf_ble_dfu.c BLE_GATTS_EVT_WRITE

nrf_ble_dfu.c BLE_EVT_RW_AUTHORIZE_REQUEST

... after this it continues the DFU procedure

Firmware Log from Failed Android DFU

nrf_ble_dfu.c BLE_GAP_EVT_CONNECTED
Max CI = 39
Min CI = 39
Slave Latency = 0
Conn Sup TO = 2000

... after this it disconnects with Error 8 (0x8) GATT CONN TIMEOUT

Android App Logs

DfuBaseService: Action received: android.bluetooth.device.action.ACL_CONNECTED

DfuBaseService: Attempting to start service discovery... succeed

DfuBaseService: Target device disconnected with status: 8

DfuBaseService: Device got disconnected before service discovery finished

...

Any ideas for how to fix?

[philips77]

Hi,
Could you paste more logs from Android, like those at the end? I'm interested what happens a bit before. Also, could you paste timestamps.
We've heard about this issue, but it usually happens rarely and I thought it was fixed some time ago. Does it happen 100% of times?

[philips77]

And I'm sorry for the delay, I was busy with other projects.

[beeboopx]

Hi Philips,

Thank you very much for your reply.

I have sniffed the connection events to the Bootloader during DFU process for both Nordic iOS and Android. I have attached the sniffer files that can be inspected in Wireshark. I have also attached the screenshots highlighting the contents of LL_FEATURE_REQ and LL_FEATURE_RSP for iOS and Android. It is just after the peripheral device sends its LL_FEATURE_RSP when the Android DFU Library never responds...

Let me know how it goes. Thank you!

Billy
Bootloader_DFU_Sniffing_Files.zip

[beeboopx]

Additionally, here is the logfile gathered from Android Device Monitor during an nRF Connect app DFU attempt. Included are the logs from the point when the main application is BLE Disconnected until the point where the Bootloader has failed to receive a response from the Android DFU Library, at which point the device BLE Disconnects and re-boots into the main application. It seems like there's probably a lot of helpful info here in addition to the BLE Sniffer results from the last message.

android_device_nRFConnect_DFU_bootloader_log.txt

[philips77]

Are you saying you have the same behavior on all the phones you use for testing?
It looks like the issue is in the SDK or your firmware, not in the library, as DFU library works on our DKs and phones we use for testing. Did you try running a sample from SDK 12.2 on a DK? Did you try SDK 13 or later?

Could you paste logs from nRF Connect or more logs from LogCat?

[beeboopx]

As stated in the original post, iOS DFU Library works flawlessly with the same 12.2 SDK + firmware.

Tested on the 3 Android phones described in OP, none of them working with Android DFU Library on my firmware.

I described in OP how tweaking the SDK bootloader example's default Min/Max Connection parameters did not bring success, as others have been able to achieve.

I can attempt a sample SDK 12.2 on a DK. Would you recommend I test by flashing "dfu_test_softdevice_bootloader_s132.hex" located in "SDKROOT/examples/dfu/ble_dfu_send_hex/test_images_update_nrf52" directory to an nRF52 DK and then update with the "dfu_test_softdevice_bootloader_s132.zip" file?

Were you able to derive any useful info from the BLE Sniffer and LogCat logs i posted already?

What more would you like to see from the logs?

Thanks,
Billy

[philips77]

Yes, that's the firmware I was taking about. The thing is I'd like to be able to reproduce your issue. I thought this "Disconnected before service discovery finished" was fixed together with fixing a race condition, but looks like wasn't.
If you get the same issue, could you give a try to SDK 13 or 14?

From the logs if like to see if you got any more ACL_* events around this second connection.

I'm sorry again for replying so slow but I'm super busy these days... I'll ask someone in support to help me with your case.

[yjwfn]

@philips77
I got the same problem.
The steps like this:

1. Start firmware update.
2. After a few second, kill my application.
3. Reconnect to device and update firmware
4. error(8) print in Logcat.

Use RF Toolbox got the same problem.

03-22 11:45:37.161 26220-26233/im.xingzhe D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=10 device=C6:7E:A1:91:6B:E9
03-22 11:45:37.171 26220-26484/im.xingzhe D/BluetoothAdapter: STATE_ON
03-22 11:45:37.171 26220-26484/im.xingzhe D/BluetoothLeScanner: Stop Scan
03-22 11:45:37.201 26220-26233/im.xingzhe D/BluetoothGatt: discoverServices() - device: C6:7E:A1:91:6B:E9
03-22 11:45:37.631 26220-27095/im.xingzhe D/BluetoothGatt: onClientConnParamsChanged() - Device=C6:7E:A1:91:6B:E9 interval=24 status=0
03-22 11:45:37.831 26220-26233/im.xingzhe D/BluetoothGatt: onClientConnParamsChanged() - Device=C6:7E:A1:91:6B:E9 interval=6 status=0
03-22 11:45:37.951 26220-26233/im.xingzhe D/BluetoothGatt: onSearchComplete() = Device=C6:7E:A1:91:6B:E9 Status=0
03-22 11:45:37.981 26220-26233/im.xingzhe D/BluetoothGatt: onClientConnParamsChanged() - Device=C6:7E:A1:91:6B:E9 interval=24 status=0
03-22 11:45:38.531 26220-26233/im.xingzhe D/BluetoothGatt: onClientConnParamsChanged() - Device=C6:7E:A1:91:6B:E9 interval=24 status=0
03-22 11:45:38.961 26220-27119/im.xingzhe D/BluetoothGatt: configureMTU() - device: C6:7E:A1:91:6B:E9 mtu: 517
03-22 11:45:39.011 26220-26232/im.xingzhe D/BluetoothGatt: onConfigureMTU() - Device=C6:7E:A1:91:6B:E9 mtu=23 status=0
03-22 11:45:39.011 26220-27119/im.xingzhe D/BluetoothGatt: setCharacteristicNotification() - uuid: 8ec90001-f315-4f60-9fb8-838830daea50 enable: true
03-22 11:45:40.321 26220-26220/im.xingzhe D/ViewRootImpl: #3 mView = null
03-22 11:45:40.341 26220-27119/im.xingzhe E/DfuImpl: Executing object failed (error 8): OPERATION NOT PERMITTED
03-22 11:45:40.341 26220-27119/im.xingzhe D/BluetoothGatt: cancelOpen() - device: C6:7E:A1:91:6B:E9
03-22 11:45:40.351 26220-26233/im.xingzhe D/BluetoothGatt: onClientConnectionState() - status=0 clientIf=10 device=C6:7E:A1:91:6B:E9
03-22 11:45:40.351 26220-27119/im.xingzhe D/BluetoothGatt: refresh() - device: C6:7E:A1:91:6B:E9
03-22 11:45:40.361 26220-27119/im.xingzhe D/BluetoothGatt: close()
03-22 11:45:40.361 26220-27119/im.xingzhe D/BluetoothGatt: unregisterApp() - mClientIf=10

[beeboopx]

FYI, this issue was resolved for my application. The issue was the watchdog timer, set in firmware, expired too quickly for the Android DFU Library to connect. The problem was the delays in Android DFU Library caused the bootloader to exit before the connection request was sent. So, when the DFU Library tried to BLE Scan for the advertising device, it was too late and issued the ERROR: GATT CONN TIMEOUT. We fixed it for our Android App by reducing the length of delays that were introduced in this pull request:

#12

We also reduced the delay times in a few other places. The combination of these delay reductions allowed timing to work with the constraints of our bootloader's watchdog timeout.

The iOS DFU Library does not have such delays. Which is why we did not see the issue with iOS.

@yjwfn your error is not the 0x8 GATT error (GATT CONN TIMEOUT), it must be a 0x8 error for something else (OPERATION NOT PERMITTED). So, better to create a new ticket for that.

I'll close the issue now. Thanks to @philips77 for helping. To be clear, it wasn't an issue with the Android DFU Library, as the delays are introduced to prevent timing errors to help the library be compatible with most Android phones. But, it is important to be aware for those of us who have a watchdog timer in their bootloader.