CC2640R2F-Q1: Resolving list issue

Hi Pawel,

0x3E - Connection Failed to be Established is most commonly influenced by the fact that the sleep clock accuracy (SCA) is not set appropriately to the 32 kHz crystal that is used on the board. What is the ppm of your LF crystal that you're using and have you set the SCA anywhere in your application?

For more information, you can refer to Section 12.5.4 of the following:

https://www.ti.com/lit/an/swra640g/swra640g.pdf

as well as the following documentation:

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_6_40_00_13/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/custom-hardware-cc13xx_cc26xx-ble.html#clock-accuracies-and-bluetooth-le

 Hi Evan,

We identified issue. It is reproducable 100% and probably You can reproduce this.

But we have doubts refer to Texas Instrument code of BLE stack

Scenario is follow:

• Please pair 10 central units with CC2640. Central has to have enabled LE Privacy.
• Please pair eleven device.

What we see. Please review function gapBondMgrAddBond

Function  static uint8_t gapBondMgrAddBond(gapBondRec_t *pBondRec, gapAuthCompleteEvent_t *pPkt)

 1) Code check, if on bonding list is already stored such device. No

Try find empty place on bonding list. Bonding list is full , so remove fist entry. Behaviour is OK

// First see if we already have an existing bond for this device
bondIdx = gapBondMgrFindAddr(pBondRec->publicAddr);
if (bondIdx >= GAP_BONDINGS_MAX)
{
bondIdx = gapBondMgrFindEmpty();
}

 2) Writing informations to bonding list.OK

gapBondCharCfg_t charCfg[GAP_CHAR_CFG_MAX];

// Save the main information
VOID osal_snv_write(mainRecordNvID(bondIdx), sizeof (gapBondRec_t), pBondRec);

// Once main information is saved, it qualifies to update the LRU table.
gapBondMgrUpdateLruBondList(bondIdx);

// Write out FF's over the characteristic configuration entry, to overwrite
// any previous bond data that may have been stored
VOID osal_memset(charCfg, 0xFF, sizeof (charCfg));

VOID osal_snv_write(gattCfgNvID(bondIdx), sizeof (charCfg), charCfg);

// Update Bond RAM Shadow just with the newly added bond entry
VOID osal_memcpy(&(bonds[bondIdx]), pBondRec, sizeof (gapBondRec_t));

3) Add device to Resolving list. Here we have got error(HCI error code0x07),that Resolving List is full. NOT OK.

#if defined (BLE_V42_FEATURES) && (BLE_V42_FEATURES & PRIVACY_1_2_CFG)
if (pPkt->pIdentityInfo)
{
// Add device to resolving list
if (gapState == GAP_STATE_IDLE)
{

HCI_LE_AddDeviceToResolvingListCmd((pPkt->pIdentityInfo->addrType &
MASK_ADDRTYPE_ID),
pPkt->pIdentityInfo->bd_addr,
pPkt->pIdentityInfo->irk,
NULL);

Why we have no here similar mehanism as on case of bonding list, that we are doing place for next devices???

It caused, that device is on bonding list, but not on resolving list.  So customer devices can not do reconnect.

Our opinion is , that this piece of code should be fixed, or should be trigerred synchronization of resolving list during pairing process.

For example we resolved issue after adding such lines on this function. Before adding device to resolving list,  do place for new devices.

gapBondRec_t tmpRec;

if((osal_snv_read(mainRecordNvID(bondIdx), sizeof (gapBondRec_t), &tmpRec)==SUCCESS) && (osal_isbufset(tmpRec.publicAddr, 0xFF, B_ADDR_LEN) == FALSE))
{
HCI_LE_RemoveDeviceFromResolvingListCmd((tmpRec.publicAddrType &
MASK_ADDRTYPE_ID),
tmpRec.publicAddr);
}

Pawel,

I apologize for the delay. I'm having someone on my team look into this for you. Regarding your message though, you seem to have added code which you state resolves the issue. Is your ask whether the code is a valid solution? Additionally, the SDK you are on is an older SDK, the latest being SDK 5.40 I believe so we will review issues fixed between to see if there is something that applies. 

Evan

Hi Evan,

To be honest, interest me, if we overlooked something, and this mechanism from sdk is OK(maybe we are not seeing of purpose, why it was implemented on such way),  . For example we can manage this also,  by trigerring synchronization of resolving list after pairing(during connection) or after directly disconnection. For example,  during disconnection, WhiteList is start sycnhronized.

But on our eyes, it will be elegant :) fix this function. Yes, we are using old SDK, because this device is old, is on the production and we are one year after SOP. Except of this issue, BLE stack working fine. To be honest I would avoid such change(new BLE stack) on this phase(series production).

Hi Evan,

is somebody checking this issue with the resolving list? No answer for a long time.

Hi Tadeusz,

Thank you sincerely for your patience. I have been able to recreate your issue on my bench.

Could you provide the source code/screenshot of where you have placed the solution code that Pawel initially provided? I agree that this would be an elegant solution and I would like to make sure that I am validating it exactly how you have implemented it.

Thank you again,
Joe

Hi Tadausz,

Thank you for providing this. Have you been able to verify this fix on your bench as well?

Best,
Joe

Hi Joe,

yes, we've tested it but only in a such exact case and it looks OK.

However, I think we should test it also with the privacy option disabled and/or possibly more option changed, because this particular option led to this issue.

So, we just have to be sure it works correctly without the side effects

Br, Taddy

Hi Tadeusz,

Our experts don't see any issue with the method by which you are implementing this solution. Pending further verification on your end, it looks like a viable solution.

I am still working to verify the fix on my bench; I will get back to you once I have.

Best,
Joe

Hi, Joe,

thank for the information. So, we're going to apply this solution but we also wait for the result "from your bench" ;)

Br, Taddy

Hi Joe,

thank you for your reply. To date, we haven't experienced any problems with this fix but we're still testing.

Br, Tadeusz