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, 

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.