CC2745R10-Q1: Issue Re-pairing After Deleting Bonding Information on CC2745

Part Number: CC2745R10-Q1


Tool/software:

When I try to pair a device again after deleting its bonding information (after it has successfully completed OOB pairing once), an error occurs.
Even reflashing the code does not resolve the issue.
Do you have any idea what might be causing this?

Details:
 1. Confirmed that the GAPBOND_PAIRING_STATE_COMPLETE event reports SUCCESS.
 2. Called GAPBondMgr_SetParameter(GAPBOND_ERASE_ALLBONDS, D_NULL_, D_NULL_) and confirmed the return value is SUCCESS.
 3. When attempting to pair again, the GAPBOND_PAIRING_STATE_COMPLETE event returns SMP_PAIRING_FAILED_UNSPECIFIED, and the pairing fails.

This bug does not always occur and is difficult to reproduce.
However, once it occurs, it will occur every time. Re-flashing the code does not fix it.

  • Hello Miyatake-san, 

    A couple of questions to start: 

    1. What SDK is being used to induce the error? 

    2. Was the device previously bonded when pairing? 

    I am setting up a test for the problem. I plan to use the same steps that you have provided above, but please let me know if the device was bonded before you started erasing all bonds. 

    Additionally, can you let me know why you are erasing all bonds after pairing is completed? 

    Thanks,

    Isaac

  • Hello Miyatake-san, 

    Can you also let me know what GAP role the device is in, and what kind of device the CC2745R10-Q1 is connecting to? 

    Thanks,

    Isaac

  • Hello Mr.Isaac,

    > 1. What SDK is being used to induce the error?
    We are using simplelink_lowpower_f3_sdk_9_10_00_83.

    > 2. Was the device previously bonded when pairing?
    Yes, the device had been paired once before. After performing a full deletion, the issue occurred when pairing again.

    > Can you also let me know what GAP role the device is in, and what kind of device the CC2745R10-Q1 is connecting to?
    It is connecting to an iPhone 16.

  • Hello Miyatake-san, 

    I have created a project to reproduce. I am erasing the bonding information after I disconnect from the phone. Then I am reconnecting the phone and pairing. I have not seen the failure yet. Can you let me know if this test is similar to what you are doing to replicate the problem? Is there anything I am missing from the flow here? 

    Where exactly are you erasing all of the bonds? Within the GAPBOND_PAIRING_STATE_COMPLETE event? Also, can I ask why you are erasing the bonds after pairing is successful? 

    Also, does a chip erase allow for the project to work afterwards? I assume erasing the chip would help restore the functionality for the short term. 

    Let me know.

    Thanks,
    Isaac 

  • Hello Mr.Isaac,

    >Where exactly are you erasing all of the bonds? Within the GAPBOND_PAIRING_STATE_COMPLETE event?
    After the GAPBOND_PAIRING_STATE_COMPLETE event has ended.

    >Also, can I ask why you are erasing the bonds after pairing is successful?
    This is because I'm testing the use case of unpairing and re-registering.

    >Also, does a chip erase allow for the project to work afterwards?
    I haven't tried chip erase. Please tell me how.

  • Hello Miyatake-san, 

    I have tested the problem more than 20 times in a row and was unable to reproduce. Can you please list the steps you are completing to reproduce the failure? 

    I will provide an answer for the chip erase tomorrow. Apologies for the delay. 

    Thanks, 

    Isaac

  • Miyatake-san, 

    Apologies for the multiple responses. I also would like to tell you how I am attempting to replicate the failure. 

    1. I connect the IPhone to the CC2745R10-Q1 device. 

    2. I pair the IPhone to the CC2745R10-Q1 device. 

    3. I disconnect the IPhone from the CC2745R10-Q1 device. 

    4. The bonds are erased with the BLEAPPUTIL_LINK_TERMINATED_EVENT, using the GAPBondMgr_SetParameter function. 

    5. I erase the bond on the IPhone. 

    6. I reconnect the IPhone to the CC2745R10-Q1 device and run the test again. 

    Let me know if this is similar to your test. Additionally, please provide the steps that you took to induce the problem. 

    Thanks,

    Isaac

  • Hello Mr.Isaac,

    The procedure is correct.
    Incidentally, we are using OOB pairing.
    I'm not sure if it's relevant, but the NVS data is configured to 80 KB.

  • Hello Miyatake-san, 

    I do not have a OOB setup easily available, but I do have an idea on how to test this on my side. I will let you know my progress by Wednesday (10/29) next week. Can you please go over the functions you are calling to complete OOB pairing, and if they are completing successfully? 

    Also to check, the parameter GAPBOND_OOB_ENABLED was set? Let me know. 

    Thanks,

    Isaac

  • Hello Mr.Isaac,

    The sequence in which SDK interfaces are called to perform OOB pairing is as follows:

    1. During initialization (u1g_BLE_SM_init function)
    GAPBondMgr_Register(&csts_bondMgrCBs) - Registers callbacks for pairing events
    GAPBondMgr_SCSetRemoteOOBParameters(&sts_remoteOobData, 0U) - Clears remote OOB data

    2.When starting the OOB pairing process
    GAPBondMgr_GenerateEccKeys() - Starts ECC key pair generation

    3.When key generation is complete (vos_BLE_SM_evtGenerateEccKeyComplete function)
    GAPBondMgr_SCGetLocalOOBParameters(&sts_localOobData) - Retrieves local OOB data (rb, Cb)

    4.Upon receiving an OOB exchange request
    GAPBondMgr_SCSetRemoteOOBParameters(&sts_remoteOobData, 1U) - Sets remote OOB data
    GAPBondMgr_SetParameter(GAPBOND_OOB_ENABLED, sizeof(uint8_t), &u1s_oobEnabled) - Enables the OOB flag

    5.After pairing is complete (vos_BLE_SM_evtBondComplete function)
    GAPBondMgr_SCSetRemoteOOBParameters(&sts_remoteOobData, 0U) - Clears remote OOB data
    GAPBondMgr_SetParameter(GAPBOND_OOB_ENABLED, sizeof(uint8_t), &u1s_oobEnabled) - Disables the OOB flag

  • Hello Miyatake-san, 

    What function did the SMP_PAIRING_FAILED_UNSPECIFIED error originate from? 

    Let me know. 

    Thanks,

    Isaac

  • Hello Mr.Isaac,

    The status SMP_PAIRING_FAILED_UNSPECIFIED originates from the event GAPBOND_PAIRING_STATE_COMPLETE.
    Does this answer your question?

    Miyatake

  • Hello Miyatake, 

    I am investigating the problem further and am working on setting up a test. I will provide a response within a week (Wednesday, 11/05). Apologies for the delay. 

    Thanks,

    Isaac

  • Hello Mr.Isaac,

    Sorry, it was not 0x08 SMP_PAIRING_FAILED_UNSPECIFIED, but rather 0x0B SMP_PAIRING_FAILED_DHKEY_CHECK_FAILED.

    Also, I confirmed that re-pairing becomes possible after performing the following steps on the iPhone:
    Settings → General → Transfer or Reset iPhone → Reset → Reset Network Settings

    Given this, could it be that the issue originates from the iPhone side and cannot be avoided purely through software on the CC2745 side?
    If there is any possible workaround or preventive measure that can be implemented on the CC2745, I would appreciate it if you could let me know.

    Miyatake

  • Hello Miyatake-san, 

    I appreciate the correction. The SMP_PAIRING_FAILED_DHKEY_CHECK_FAILED failure is more limited in scenarios than SMP_PAIRING_FAILED_UNSPECIFIED. 

    There are a few scenarios where this error will be seen. 

    1. If the public key received, is not the same as the public key sent. 

    2. If the DH (Diffie Hellman) key from the device attempting to pair with the CC27xx device is larger or smaller than the expected DH key length. 

    3. Or if DH key generation on the CC27xx fails. 

    I will continue to look into the issue. To ask a few more questions, are you generating DH keys on the CC27xx side? Is the IPhone generating and sending DH keys to the device? Please let me know. 

    Thanks,

    Isaac

  • Hello Isaac,

    My understanding is that the DH key is generated on both devices.

    Each device generates its own private key and exchanges public keys.
    Then, each side internally calculates the shared DH key using its own private key and the peer’s public key.
    The DH key itself is never transmitted; only public keys, random values, and confirmation values are exchanged.

    Signals such as Pairing Request, Pairing Public Key, Pairing Random, and Pairing DHKey Check are triggered by the iPhone side.

    Miyatake

  • Hello Miyatake-san, 

    Yes, the public keys are not the same is one of the possible errors. I need to dig into why this could be happening. Fortunately, I am very close to having a tests setup completed, so I can run some tests. Unfortunately, if this is a phone side issue, I will not be able to replicate the problem on my side since I am testing CC27xx to CC27xx. 

    Thanks,

    Isaac