Solved DFU disconnected problem for Android 10 but results in increase in GATT Error

[Mxoh]

Hi there!

We faced the problem of not being able to perform Legacy DFU with Android 10 and newer iOS devices and have since applied the fix. However, since doing so we observed that there are more instances of GATT error. We have been monitoring DFU failures in our app and you can see a trend after applying the fix at around mid/end Aug, the DFU disconnected problem users decreased but GATT error users increased significantly. 

[Hung Bui]

Hi Mxoh, 

Could you let me now which exact fix you used regarding legacy DFU and Android 10 & iOS ?

Have you managed to reproduce the issue inhouse ? or you have only received the report from the customers ? If you can reproduce the issue I would suggest to capture a sniffer trace so we can have more understanding of the issue. 

[Mxoh]

Hey Hung Bui

I just checked with my Android developer and we are using this library: https://github.com/NordicSemiconductor/Android-DFU-Library. We downloaded and added it into our app changing one line in the file LegacyButtonlessDfuImpl.java at line 198 to restartService(newIntent, /* scan only for SDK 6.1, see Pull request #45 */ true); to solve the problem of Samsung + Android 10 DFU disconnected problem. 

We haven't been able to replicate the issue in-house as we don't know what model or phones are showing up with GATT Error. Would it be helpful if we provided you with the zipped file of the DFU library? 

[Hung Bui]

Hi Mxoh, 
So in the fix you did, you forced scanning for different address of the advertiser ? 
I'm not 100% sure it would fix the issue described in here: https://devzone.nordicsemi.com/f/nordic-q-a/60658/not-able-to-perform-legacy-dfu-with-android-10-and-ios
The issue described in the case was about that the DFU bootloader may advertise in directed advertising mode when the central device already changed the address. By having the address changed the central won't be able to connect to the DFU bootloader. (even if you try to scan for the advertising packet, the directed adveritising will not show up if the target address doesn't match)

The best solution for this is to modify the DFU bootloader to not advertising in directed advertising and use the normal advertising instead. Or to bond to the central to get the IRK, but I guess it's not the case here. 

We would need to have the sniffer trace and maybe DFU log on both the phone side and the nRF52 side when the GATT error happens. 

[Mxoh]

This workaround was suggested because we had to modify firmware to delete dfu_app_peer_data_set so as to fix the DFU disconnected problem. More information on why we did this workaround is explained here: https://devzone.nordicsemi.com/f/nordic-q-a/66015/how-can-ios-dfu-library-v4-8-0-work-with-the-sdk11-workaround-delete-dfu_app_peer_data_set-in-application-of-firmware/272714#272714

Let me see if I can get the other information for you. 

[Hung Bui]

Hi Mxoh, 

Thanks for the clarification. So let's me sum up. You have implemented the fix in the application to erase the bond information before forwarding to the bootloader. Therefore the bootloader will now advertise with address +1 instead of the original application address. 
And because of that you have updated the iOS/android app to scan for the address +1 if after 2 seconds it couldn't find the device original address.

Currently we don't know what the GATT error exactly about, we would need either a log from the bootloader, or a sniffer trace to get to know what caused the issue. 

In the PR Aleksandre wrote: 

• When working with Legacy DFU devices, that may or may not advertise with address + 1, and after setting DFUServiceInitiator. forceScanningForNewAddressInLegacyDfu to true, the library will first try to connect to the same peripheral instance for 2 sec (the original DFU bootloader uses direct advertising with very small advertising interval, so this should work), and will start scanning for a device matching peripheral selector on timeout.

Please check if your bootloader advertises in the original address or the +1 address. I am suspecting if it advertise in original address and if the central couldn't establish the connection in 2 seconds it will start looking for the +1 address. And for some reason if your bootloader stick to the orignal address (or stick to directed advertising) then the connection won't be established. 

[Mxoh]

Sorry for the late response Hung Bui as I needed my developers take on it. Currently our devices broadcast the +1 address. In that case, we definitely need to get a log from the bootloader, or a sniffer trace of an actual device that met with GATT error to determine the cause right? 

[Hung Bui]

Hi Mxoh, 
Yes, we need to see a sniffer trace to understand what happened between the iPhone and the bootloader. The log from the bootloader also nice to have. 

I suspect that the phone didn't do a service discovery (it somehow cached a previous version of the attribute table). To avoid that, both the bootloader and the application should enable Service_changed characteristic (set NRF_SDH_BLE_SERVICE_CHANGED = 1 in sdk_config.h)

[Mxoh]

Hey Hung Bui, 

Thanks for your help so far. The problem is that we haven't been able to replicate the problem on our end and can only tell by the analytics numbers that GATT Error is something our users are experiencing. If we don't replicate the issue but still pass you the sniffer trace, would it still be useful? We are worried if this GATT Error snowballs into the DFU device disconnected problem we had. 

[Hung Bui]

Hi Mxoh, 
Could you please check the NRF_SDH_BLE_SERVICE_CHANGED value in sdk_config.h ? (in both the application and the bootloader)

You can send us the sniffer trace even though it does have the GATT error. It would contain some information about your DFU process that we are interested in.