DFU issues on Android 10

[AntonHellbe]

Hi,

We are currently testing DFU upgrades on Android. In my current setup I have two different phones, a Sony one running Android 8 and a OnePlus running Android 10.

The bootloader uses bonds and the application uses the buttonless DFU service.

Entering the bootloader and performing a DFU upgrade through the nRFConnect App on the Sony phone works fine. No failures there.

However on the OnePlus there are some issues. The first issue is that when trigger a DFU with the new FW zip file the nRF52832 enters the bootloader, the OnePlus connects again, but at reconnect it receives "GATT_INVALID_HANDLE", like it does not receive the GATT_SERVICE_CHANGED notification or that it receives it too late.

The second issue is that sometime the application cannot enter the bootloader from the buttonless DFU service, these are the logs from the application when I'm writing to the characteristic from the OnePlus:

<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation

Hardware: nRF52832 PCA10040

SDK: v15.0

Softdevice: v6.0.0

Edit: added screenshots from LOG

[Einar Thorsrud]

Hi,

Both these issues could be explained by missing service changed. Have you made sure the NRF_SDH_BLE_SERVICE_CHANGED is set to the same value in both the applications and bootloaders sdk_config.h? What is it?

[AntonHellbe]

Hi again,

Here is another screenshot from my OnePlus 5 running Android 9, attempting DFU through the NRF Connect App.

I've never had any issues on this phone before.

[AntonHellbe]

2816.sniffer.pcapng

Hi,

Here's the sniffer trace from wireshark. At package 6130 the connection to the bootloader starts.

Hopefully you can read the data, I'm not very experienced with wireshark so I dont know if this is the correct way to do it.

The sequence is here is write to DFU characteristic to "manually" put it in bootloader and then connect.

[Einar Thorsrud]

Hi,

Thanks. All looks good here as far as I can see. I am wondering if there could be a timing issue in the Android DFU library itself, as you suggested earlier. Perhaps fixed by this. I am checking with the library developer and will get back to you.

[Einar Thorsrud]

Hi,

Looking more closely at this with one of our Android developers he commented hat from the log is seems like the phone did receive SC indication, as it switched to 7.5 ms connection interval (which it does for service discovery), but it did receive it too late. The DFU service has already received cached services from the system and tries to use them. Service discovery was delayed 1.6 sec, but that seems not to be enough for the device, as 300 ms later the SC indication comes. Had it come earlier, the system would have cleared the cache, performed service discovery and returned the new services to the DFU library.

You can try to fix this in your app by including the library as a module, not from jcenter, and modify this line to be > 2000 ms. You can also try fixing in the bootloader by always sending a service changed indication earlier (if enabled), i.e. before getting the BLE_GATTS_EVT_SYS_ATTR_MISSING or BLE_GAP_EVT_CONN_SEC_UPDATE event.

[AntonHellbe]

Hi Einar,

Thanks for the update. We will try both solutions and see what works best.

Regarding sending a service changed indication earlier than BLE_GATTS_EVT_SYS_ATTR_MISSING or BLE_GAP_EVT_CONN_SEC_UPDATE, do you have any suggestions on what event would be appropriate to use for sending the service changed indication?

Br,
Anton

[Einar Thorsrud]

Hi Anton,

Good question. It is not logical in my mind to send it before BLE_GAP_EVT_CONN_SEC_UPDATE, since that is when we know we are connected to a known peer (which has hopefully enabled service changed indications). You could try to send it before, but it anyway should not be before the peer has enabled indication (since you cannot know it is the same old peer before the link is encrypted). You could try to send in on the BLE_GAP_EVT_CONNECTED, or start an app_timer to send it a certain delay after.

I am surprised that the phone handles it like this. It would be interesting to know why this is so slow on the phone side, but no progress there yet.