Android asking for pairing after DFU

[Randy Lee]

Using SDK 15.3 on the embedded side and Android 10 I think it is on the mobile side.

We've implemented whitelists and hanging onto the bonding information on the embedded side.  The idea is that once the mobile side is talking to us we only want to talk to that particular device until we explicitly change to another one.

This works fine across power cycles on both sides.  Once paired and bonded and everything, the mobile side and embedded side exist in married bliss.

Now, pull up nRF connect and run a DFU on the embedded side. Once the embedded side comes back (and it is keeping all the bonding information and whitelists and all that across this as far as I can tell), Android wants to pair again...

I just don't understand why this is.  We've got the bonding information both sides as far as I know. Why does the Android side really want to pair again?  Am I missing something on the embedded side?

[Edvin]

Hello,

So it is after the update is complete, and you try to connect to it again like it was before (in the married bliss) that it wants to pair again, is that correct? 

Do you see whether the peripheral device has changed anything? Or did you try to debug the applciation? Is the bonding data still present on the peripheral? Does the peripheral use the same Bluetooth LE address as before the DFU update took place?

Best regards,

Edvin

[Randy Lee]

yes, after the DFU has completed. Everything should be the same as before the update as all that information is being saved as far as I know...  Power cycles of either side of that prior to DFU does not cause this repairing request so I'm pretty sure it's being saved.

Android itself is popping a "you want to pair?" message.

[Einar Thorsrud]

Hi,

I have inherited this case from Edvin.

Looking at connection after DFU.pcapng, everything looks normal, as if connecting to a device with no existing bond. My first gut feeling after reading this thread was that perhaps the nRF BT address was different, but that is the same in both traces, so that is not it. Could it be that your custom app for some reason deletes the bond when performing DFU? Are you able to reproduce this using only nRF Connect for mobile and not your app at all (make sure it is not running in the background as well)?

Einar

[Randy Lee]

about the DFU port: This is pretty much a straight up SDK.. the backport from another SDK is in the main application not the bootloader itself.

[Randy Lee]

Greetings Einar!

Yes, this is generally reproduced using mobile version of nRFconnect on Android phones.

[Randy Lee]

thought:  The device is using all the normal Nordic code and mechanisms for this stuff along with the soft device.  Keys and such are stored in FDA areas as usual (see above).  Is it possible for the android app to be asking for connections and keys before something is ready on the device side to deal with it so that it thinks that the information hasn't been stored?

Thinking outside the box here. I don't see how, but then again, things happen with embedded systems that aren't always obvious.

[Einar Thorsrud]

Randy Lee said:

Is it possible for the android app to be asking for connections and keys before something is ready on the device side to deal with it so that it thinks that the information hasn't been stored?

I did not test this, but if you start advertising before initializing the peer manager that might be the case. Normally you will do all initialization in the firmware before starting to advertise, though. Can you check that in your firmware?

However, I do not expect this is the issue. Normally, if the bonds were lost on the nRF for some reason, the Android phone would first try to secure the link using the existing bond, and if that does not exist on the nRF, securing the link would fail and it would disconnect. However, in both your description and the sniffer trace there is no sign of the Android trying to secure the link using an existing bond. Instead, it attempts to bond right away. This is not expected behavior. Can you double check if the bond gets erased on the Android at some point before connecting again after the DFU? (I cannot say what should delete it).

Randy Lee said:

about the DFU port: This is pretty much a straight up SDK.. the backport from another SDK is in the main application not the bootloader itself.

I see. Based on what I have seen so far there is nothing pointing to an issue in the nRF firmware, but for some reason the Android device misbehaves (trying to re-pair to a device it is already bonded to). The question is why this happens. And to be frank, I have never seen any reports of this before.