Failure on DFU process (Android)

RE: Failure on DFU process (Android)

Carmelo Ruota — Wed, 14 Dec 2022 14:55:32 GMT

Hi Aleksander Nowakowski
Unfortunately, changing the reboot time as you described didn't work.

RE: Failure on DFU process (Android)

Aleksander Nowakowski — Mon, 12 Dec 2022 09:28:31 GMT

From the logs I see that the device needs ~12 seconds to reboot and start advertising directly. Did you try setting the reboot time using https://github.com/NordicSemiconductor/Android-DFU-Library/blob/38dad6229fa949dca090cfc8a65aa26f0e4ea7f9/lib_dfu/src/main/java/no/nordicsemi/android/dfu/DfuServiceInitiator.java#L299 ? So that the following connection is delayed until the device is "for sure disconnected". You may set it to 15 sec, or something like.

Also, do you know why it takes so long for it to reboot? Is it expected?

RE: Failure on DFU process (Android)

Carmelo Ruota — Mon, 12 Dec 2022 09:14:42 GMT

Hi, any update?

From our side, no further progresses.

RE: Failure on DFU process (Android)

Aleksander Nowakowski — Wed, 23 Nov 2022 20:48:38 GMT

I'll look at the traces tomorrow. You may also try initiating dfu majorally on the phone where it works and trying to connect on the device under test.

RE: Failure on DFU process (Android)

Carmelo Ruota — Thu, 17 Nov 2022 10:51:53 GMT

Hi Aleksander, we tried as you described with the following steps:
- from NrFConnect app we connected to the BLE device starting the DFU process writing on the characteristic
- then, the BLE device is rebooted waiting for "someone" to connect
- trying to connect to the BLE we wasn't able to connect

Trying the same process from another phone the process was ok

I've attached both logs.

devzone.nordicsemi.com/.../0486.manual_5F00_fota_5F00_KO.pcapng

devzone.nordicsemi.com/.../8814.manual_5F00_fota_5F00_OK.pcapng

Thanks

RE: Failure on DFU process (Android)

Aleksander Nowakowski — Fri, 04 Nov 2022 16:53:30 GMT

Try repeating the initial steps using nRF Connect for Android on those phones that done work. But manually. Connect, enable notifications and send Dfu Start command. This should trigger notification and disconnection. When finally does, try to reconnect and see it that works during those 30 sec of direct advertising.

If possible, please provide the logs.

Have a good weekend!

RE: Failure on DFU process (Android)

Aleksander Nowakowski — Fri, 04 Nov 2022 15:21:09 GMT

Thank you for sending the log, I may have a clue now.

You're using Legacy DFU. In the default implementation of Legacy DFU the bootloader, after switching from app mode, starts advertising with Direct Advertising using the same MAC address.

In frame 170 the app sends "Jump to bootloader" command (0x0104). This should be replied with a notification 0x0601, but I don't see that in the sniffer logs. That's issue number 1.

Instead of rebooting (Issue number 2) to the bootloader mode immediately, the device holds connection to the phone for next 12 seconds until frame 206, when it finally sends LL_TERMINATE_IND:

Error Code: Remote User Terminated Connection (0x13)

Here how it looks from Android side (your listing Samsung S9 2nd attempt):

// Android sends "Jump to bootlaoder command"
A 16:20:42.295 [DFU] Jump to bootloader sent (Op Code = 1, Upload Mode = 4)

// It doesn't wait for the notification (no reason to, disconnects instead)
D 16:20:42.295 [DFU] gatt.refresh() (hidden)
D 16:20:42.312 [DFU] gatt.disconnect()
D 16:20:42.312 [DFU] gatt.close()

// And restarts hoping to connect to bootlaoder mode
V 16:20:42.345 [DFU] DFU service started
I 16:20:42.345 [DFU] Firmware file opened successfully
D 16:20:42.345 [DFU] wait(1000)
D 16:20:43.331 [DFU] wait(1000)
V 16:20:44.346 [DFU] Connecting to DFU target...
D 16:20:44.347 [DFU] gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferredPhy = LE_1M | LE_2M)

// The library gets CONNECTED state, as... the device is still connected here (didn't reboot)
I 16:20:44.368 [DFU] Connected to FF:EC:FF:FE:CE:66
V 16:20:44.368 [DFU] Discovering services...
D 16:20:44.368 [DFU] gatt.discoverServices()

// Here Android does something weird. 
// Usually, before service discovery it switches to 7.5 ms interval, so it tires to,
// but as it's in a weird state, no such packet is sent.
I 16:20:45.091 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)

// Finally, the termination sent from the slave is received.
D 16:20:54.868 [Callback] Connection state changed with status: 19 and new state: DISCONNECTED (0)
W 16:20:54.869 Connection terminated by peer (status 19)
I 16:20:54.869 Disconnected
E 16:20:54.979 [DFU] Connection failed (0x13): GATT CONN TERMINATE PEER USER

The termination matches one sent from the device (0x13).

Then, 5 seconds later, the device begins advertising directly for 30 seconds.

DFU library tries to connect twice and fails (Issue number 3, the main one). There may be different reasons for the failure. Most probably, it is related to how Android started reacting to Direct advertising. Have a look at: https://github.com/NordicSemiconductor/Android-DFU-Library/blob/38dad6229fa949dca090cfc8a65aa26f0e4ea7f9/lib_dfu/src/main/java/no/nordicsemi/android/dfu/DfuServiceInitiator.java#L334 and https://github.com/NordicSemiconductor/IOS-DFU-Library/pull/374

Some phones, as we observed, don't respond to direct advertising correctly, they don't connect to it. The solution was to modify the bootloader to use +1 address instead and ADV_IND, not ADV_DIRECT_IND. Then you'd have to set the flag from the first link to make the app scan for a new address after switching to bootloader mode. You may try it if you have a way to trigger dfu mode with a button. Then it should be using normal advertising, as no data are passed from the app, I think.

Also, investigate why the device does not reboot properly just after switching to bootloader mode. Perhaps this is the root cause?

RE: Failure on DFU process (Android)

Amanda Hsieh — Thu, 27 Oct 2022 13:45:51 GMT

We cannot find anything interesting there. That's why we ask for the ble sniffer log.

-Amanda

RE: Failure on DFU process (Android)

Carmelo Ruota — Thu, 27 Oct 2022 13:38:39 GMT

Hi Amanda Hsieh we're trying to retrieve a dongle in order to sniff BLE traffic. In the meantime, is the attachment btsnoop_hci_202209131717.cfa enough for the analysis?

RE: Failure on DFU process (Android)

Amanda Hsieh — Thu, 27 Oct 2022 13:10:57 GMT

Hi,

Please provide a ble sniffer log as Aleksander required.

-Amanda

RE: Failure on DFU process (Android)

Carmelo Ruota — Thu, 27 Oct 2022 07:48:13 GMT

Hi Aleksander, do you have any updates regarding the latest information we have provided?

Thank you.

RE: Failure on DFU process (Android)

Carmelo Ruota — Wed, 14 Sep 2022 09:10:11 GMT

Hi, we retried a test on Samsung S9 and recovered the hci logs from the smartphone. The device's address we tried to put in DFU for the test case is DC:95:CC:CE:BF:9E, attached the logs.

Thank you.devzone.nordicsemi.com/.../btsnoop_5F00_hci_5F00_202209131717.cfa

RE: Failure on DFU process (Android)

Carmelo Ruota — Mon, 22 Aug 2022 13:59:57 GMT

Hi Aleksander, The nRF5 SDK version is 10.0.0
I'm going to try to use a sniffer log hoping to get back to you with details.

Regarding the bluetooth, we restarted it and also the phone.

Thanks for your support.

RE: Failure on DFU process (Android)

Aleksander Nowakowski — Wed, 17 Aug 2022 16:32:33 GMT

Which nRF5 SDK is your fw based on?

Did you try a different Samsung S9 phone? Does it work sometimes, or never on this phone? Did you try restarting Bluetooth or the phone?

A sniffer log could be helpful, but if the lib works on most phones, but fails on some, most probably it's an issue with that phone, but the library. There may be some workarounds, that can be done, but that's not always possible. Anyway, replicating it on our side would also help.

RE: Failure on DFU process (Android)

Carmelo Ruota — Wed, 17 Aug 2022 15:53:42 GMT

It seems that also the library version 2.1.0 doesn't fix the issue
Trying on Samsung Galaxy S9, we obtain the same error reported. What I can provide in order to deeply analyze?

RE: Failure on DFU process (Android)

Aleksander Nowakowski — Mon, 08 Aug 2022 11:44:25 GMT

Hello,

I think I may know why this issue happens. I'll was about to release a new version of the library (2.1.0), which should solve your issue.

The issue has been introduced here: https://github.com/NordicSemiconductor/Android-DFU-Library/pull/319

In order to improve reconnection speed I removed awaiting disconnection. However, this should only be removed for devices that change the MAC address in bootloader mode. If the bootloader uses the same MAC, like in your case, or in Secure DFU when the device uses Buttonless Service with Bonds, the phone has to await disconnection, or will use the same connection instead even before it closes. Then it goes into a weird state and starts throwing 133 (0x85).

Please, check version 2.1 when it's out.