Handover DFU connection

[Daniel]

Hi,

Instead of initiating the DFU library in Android with an address is it possible to handover a existing GATT connection to a device already in DFU mode?

We have cases where we in our app is detecting devices in DFU mode. We haven't experienced any problems connecting to those from our app but we have experience many problems disconnecting the device and handing over address to DFU library for connection. We have moved to DFU v1.3 and have seen some commits laborating with sleep time, but still we randomly experience problems. Doing re-retries will eventually fix the problem but gives a bad user experience.

[bjorn-spockeli]

Hi Daniel, I am not sure if it is possible to handover an existing connection, as the nRF device must reset in order to enter bootloader mode, which means that the connection has to be broken. Could you elaborate regarding the issues you've seen with handing over the address to the Android DFU Library?

Could you elaborate

[Daniel]

Hi,

About handover, our app has in some case (e.g. out-of-range) connected to the device in bootloader mode. So it seems unnecessary to reset and enter bootloader, dfu mode again.

Regarding what goes wrong, our internal stats looks like this:

(state, count, unique_devices, msg)

• successful, 940, 368, -

• failed, 187, 48, DFU error: DFU DEVICE DISCONNECTED

• failed, 4, 4, DFU error: REMOTE DFU OPERATION FAIL

• failed, 2, 2, DFU error: BLUETOOTH ADAPTER DISABLE

• failed, 1, 1, DFU error: DFU SERVICE NOT FOUND

• failed, 1, 1, DFU error: GATT INTERNAL ERROR

[bjorn-spockeli]

About handover, our app has in some case (e.g. out-of-range) connected to the device in bootloader mode. So it seems unnecessary to reset and enter bootloader, dfu mode again.

If the device already is in bootloader mode, then the DFU library will not trigger another reset. It reads the DFU version characteristic, which determines if the device is in application mode and a reset to the bootloader is necessary. Judging by the error log it could look like the nRF device encounters an error during the DFU procedure resulting in the REMOTE DFU OPERATION FAILED error.

[Daniel]

Great. Doing handover will in some case avoid user getting multiple fails in a row.

Still we have really bad stats for the first try. All/most problems are related to connecting after a reset. That's why I mentioned the sleep times that you are laborating with e.g. commit c1455e2b. Once DFU lib is connected it "always" goes well (if not going out-of-range, bt toggle, turning off phone).

Are the stats according to expectations? What success/fail ratio should we expect?

[Aleksander Nowakowski]

Hi Daniel,

You don't have to disconnect in your app before starting DFU. You will eventually get the onConnectionStateChanged callback with newState=DISCONNECTED when you just start the DFU. On Android every app may have a number of BluetoothGatt connections to a device. They all behave as they were the only one, but it doesn't have to be true. The physical connection will be terminated when the last one of those is disconnected.

So what you may do is, when you connect to your device (no matter if it's in bootloader on in app mode), just start DFU providing the device address, as you do right now. The BluetoothGatt object of BluetoothGattCallback can't be passed to the service, so handing over the existing connection object is not possible, but when you won't disconnect before starting DFU the same physical connection will be used. Some time after you started DFU you may disconnect, when the library has already created its own connection object, but also you don't have to. When DFU is completed (or the first part of it) you'll get the disconnected event as it the device just disconnected itself. You may actually sniff the packets in your app, your connection, sent by the device during DFU by calling setNotificationsEnabled(DFU Control Point char, true), but it may add some delays and I wouldn't recommend it.

Hope that helped.

BR, Aleksander