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.

[Randy Lee]

TOok some time as we had to get the hardware to do this, but attached are the sniffer logsconnection after DFU.pcapngnormal connection.pcapng

[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.