• State Not Answered
  • Replies 31 replies
  • Subscribers 62 subscribers
  • Views 3685 views
  • Users 0 members are here
Attachments (6) Download All
Nordic Case Info
  • Case ID: 289881
Options

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?

  • 0

    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

  • 0 in reply to Edvin

    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.

  • 0 in reply to Randy Lee

    Ok, so one of your devices has probably lost the bonding data, if your peripheral hasn't changed address.

    There is a setting in the sdk_config.h of your bootloader to determine how many FDS pages your bootloader should preserve through a DFU. How many FDS pages is your application using? And what does the setting say in your sdk_config.h of your bootloader?

    You can also make your application to tell you how many peers that are stored in the beginning of your application, to verify that it is in fact the nRF that has lost the bonding data. What does it say?

    Best regards,

    Edvin

  • 0 in reply to Edvin

    I used to know the variables involved in this in the sdk_config.h files but I can't find them just now... what variable names are you after in particular here?

    We only allow exactly one connection/pairing/bonding at a time enforced through the whitelist stored in FDS and some interaction with things.... 

    I remember I had quite a fight months ago keeping FDS over a DFU but don't recall what I had to set to do it...

  • 0 in reply to Randy Lee

    It is the one called NRF_DFU_APP_DATA_AREA_SIZE in SDK15.3.0. By default this is set to 12288, which equals 3 flash pages (3 * 1024 words = 3*1024*4).

    So in your application's sdk_config.h file, how many flash pages does your application use? (what is FDS_VIRTUAL_PAGES and FDS_VIRTUAL_PAGE_SIZE in sdk_config.h?)

Related