• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 1307 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BLE bonding Bluetopia v4.0.2.2

Jerome Godbout86
Intellectual 330 points

Other Parts Discussed in Thread: CC2564MODN

Hi, thanks to Vihang for his help so far it's appreciated!

I can now perform my OOB connection with my CC2564MODN radio and STM32F4 MCU board. I have the pairing done and the encryption key are exchanged. Now If I want to do a bonding, I need to keep the LTK key exchanged during the key exchange, I guess this is done during:

GAP_LE_Authentication_Event_Data_t latEncryptionInformation (on the Central device only?)

Does the radio or the stack have API to store the information that stick between reboot? or do I have to store this information inside my MCU NVRAM?

How does the central unit perform a bonding connection?

My guess so far, is I need to fetch the info inside

BSC_SearchGenericListEntry()

Upon the device boot I would need to fill an entry from NVRAM info with:

BSC_AddGenericListEntry()

The follow flow is what I expect:

  1. Central try to connect to the device (scan or not) or peripheral try to request a connection
  2. upon connection completed (instead of calling the GAP_LE_Pair_Remote_Device) I need to call the GAP_LE_Reestablish_Security with the info from the BSC_SearchGenericListEntry()

Is saving the whole BSC List head entry a good idea? or should I only need the LTK and device address when a successful pairing occur?

How does the bonding work with random address? do I need to make IRK resolvable address and keep the public address of the device (exchange the IRK, resolve the random address with the IRK to keep only the public address into the NV memory with the LTK and IRK)? This imply  that now I should always use random address create with GAP_LE_Generate_Resolvable_Address() and ditch the GAP_LE_Generate_Static_Address() or  GAP_LE_Generate_Non_Resolvable_Address() which might not be a good idea anyway, felt more secure but might not with bonding).

The goal here is to use both device on cradle for initial OOB exchange, then whenever the device start BLE radio and are ready to go outside the cradle, they pair to each other (which work so far). But I would like them to be able to shutdown and power up again and still working until peripheral is put into another cradle. So I need this bonding feature.

Thanks, regards,

Jerome

  • 0
    Intellectual 330 points

    Just wondering what is the effect of bonding value inside

    GAP_LE_Pair_Remote_Device(
  GAP_LE_Pairing_Capabilities_t Capabilities
  {
      GAP_LE_Bonding_Type_t Bonding_Type;
  }
)

    I set it to lbtBonding, but I'm not sure what it really does??? is something save somewhere automatically? does the stack does something with it? Do I have to save the exchanged key maually into the latEncryptionInformation event?

    Since I'm on a OOB connection, I wonder if I only could keep the exchanged key and make the pairing over again (but I think this might require more energy).

  • 0 in reply to Jerome Godbout86
    Intellectual 330 points
    I seem to have find some information, I was not handling the latIdentityInformationRequest and latIdentityInformation case inside with GAP_LE_Authentication_Event_Data_t. I guess this is the stack required data request to store the device identifier for the bonding if I'm not mistaken.

    SO if I get this right the Peripheral should implement the latIdentityInformationRequest to give it's own info to the central. The central on the other hand should implement the latIdentityInformation that need to be stored for this device in order to connect to it again when doing a bonding.

    I guess I should store this information along the LTK and public address of the device into central NV memory? This is the info I should pass back to the GAP_LE_Reestablish_Security() once I can connect again to the device instead of GAP_LE_Pair_Remote_Device() call?
  • 0 in reply to Jerome Godbout86
    TI__Expert 6335 points

    Jerome,

    Apologies for the delay in response, Vihang has been rather busy with other tasks. You are correct, you can store the LTK and Identity information in NVM so that it is there upon reboot, and after rebooting, copy that information back into the appropriate fields. This will allow the devices to connect without having to go through the whole pairing process, as they will already be paired with the correct LTK, and will just have to connect.

  • 0 in reply to dale
    Intellectual 330 points
    Thanks, this seem like the right way, I'm still looking to see if I should do OOB paring and avoid storing the LTK and only the OOB key. This might make the pairing a little longer but not that much of a problems since OOB is user less implication.