• State
  • Replies 6 replies
  • Subscribers 51 subscribers
  • Views 232 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

CC2745R10-Q1: About GapBondMgr_writeBondToNv and GapBondMgr_readBondFromNV

CC2745R10-Q1: The constraints when reading bonding information (GapBondMgr_readBondFromNV) in SDK 9.10

Yukine Okita
Prodigy 80 points
Part Number: CC2745R10-Q1

Tool/software:

Please provide guidance on the restrictions for reading bonding information (GapBondMgr_readBondFromNV) in SDK 9.10.

Since bonding information is written upon executing pairing, we wait for the completion of bonding information writing (GAPBOND_PAIRING_STATE_BOND_SAVED),
but operations differ as described below in scenarios ① and ②:

① If you read bonding information immediately after completing the bonding information writing, the API for reading bonding information becomes unresponsive.
② If you wait for 100ms after completing the bonding information writing and then read the bonding information, the reading succeeds.
※Point ② was a misunderstanding during the operation check. Regardless of the waiting time, the loading of bonding information fails.

I expect the bonding information reading to succeed in operation ①. Please provide guidance on a method to achieve this.

Additionally, in SDK 8.30, reading bonding information (gapBondMgrReadBondRec) immediately after completing the writing works correctly.

Best Regards,
Yukine

  • 0
    TI__Genius 14785 points

    Hello,

    What is the error code you are receiving from the API?

    Best,

    Nima Behmanesh

  • 0 in reply to Nima
    Prodigy 80 points

    Hi,

    The API for reading bonding information (GapBondMgr_readBondFromNV) becomes unresponsive, so I cannot check the API error code.
    Please tell me how to check the error code.

    Best Regards,
    Yukine

  • 0 in reply to Yukine Okita
    TI__Genius 14785 points

    Hello,

    Please elaborate on what you mean by "becomes unresponsive."

    1. Does the chip become unresponsive? If so, attach a debugger and get a callstack for me to analyze so I can identify the halt.

    2. Are you using Out-of-Band pairing?

    Best,

    Nima Behmanesh

  • 0 in reply to Nima
    Prodigy 80 points

    Hi,

    > 1. Does the chip become unresponsive?
    > If so, attach a debugger and get a callstack for me to analyze so I can identify the halt.

    Our verification method was not appropriate, and the API was in fact responsive.
    However, since it is still not behaving as expected, we would appreciate your continued guidance.

    After the initial BLE connection and completion of pairing, when we attempt to read the bonding information (GapBondMgr_readBondFromNV), it returns bleGAPBondItemNotFound (0x36).
    Our understanding is that the bonding information should be saved to Non-Volatile Memory sometime between the initial BLE connection and the completion of pairing. Is this correct?
    Also, is there a way to verify whether the bonding information has actually been written to Non-Volatile Memory?

    > 2. Are you using Out-of-Band pairing?
    Yes, I use it.


    Best Regards,
    Yukine

  • 0 in reply to Yukine Okita
    TI__Genius 14785 points

    Hello,

    Yukine Okita said:
    After the initial BLE connection and completion of pairing, when we attempt to read the bonding information (GapBondMgr_readBondFromNV), it returns bleGAPBondItemNotFound (0x36).

    This is return code is somewhat poor, in that there isn't a real issue. This will actually be changed in the next release of the SDK.

    The reason this return code occurs is because the peer devices LTK is missing, but this is to be expected since the peer device LTK does not have to be distributed. 

    As stated above, the next SDK will have a fix for this that will remove this return code.

    You can also verify this yourself by reading the contents of the bond record when this issue occurs. You'll find that the devLTK is missing, but again this is to be expected.

    Yukine Okita said:
    Also, is there a way to verify whether the bonding information has actually been written to Non-Volatile Memory?

    Since you're receiving 0x36 and not 0x34, the bond information is in Non-Volatile memory. Otherwise this API would return a different error code. This function actually receives the bond record from the NV region, so again, the return code would be 0x34 it did not exist at all.

    Best,

    Nima Behmanesh

  • 0 in reply to Nima
    Prodigy 80 points

    Hi,

    Nima said:
    Since you're receiving 0x36 and not 0x34, the bond information is in Non-Volatile memory.

    If bleGAPBondItemNotFound (0x36) is returned, I would like to know how to retrieve the bonding information.
    As in the SUCCESS case, is it possible to obtain the bonding information from the fourth argument, pBondRecord?


    Best Regards,
    Yukine