Handover DFU connection

RE: Handover DFU connection

Aleksander Nowakowski — Fri, 28 Apr 2017 11:22:23 GMT

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

RE: Handover DFU connection

Daniel — Tue, 25 Apr 2017 12:42:06 GMT

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?

RE: Handover DFU connection

bjorn-spockeli — Tue, 25 Apr 2017 12:33:06 GMT

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.

RE: Handover DFU connection

Daniel — Tue, 25 Apr 2017 11:53:36 GMT

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

RE: Handover DFU connection

bjorn-spockeli — Tue, 25 Apr 2017 10:59:50 GMT

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