• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 114 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.

Original question:

CC2651R3: Update: CC2651R3: Previously bonded devices can not connect in whitelist mode

CC2652PSIP: I am unable to connect to the whitelist advertisement when the devices are bonded.

D.V.L.
Prodigy 55 points
Part Number: CC2652PSIP

Tool/software:

Hello there,

I'm experiencing the same issue described by Vikas R. J. and Kaiwalya Belsare, but their proposed workaround is not completely effective.

I'm using a CC2652PSIP with custom firmware based on Project Zero, as well as TiRTOS, TiCLang v4.0.3, and the SimpleLink CC13xx/CC26xx SDK v8.30.1.01.

When I use the proposed workaround, after calling setBondManagerParameters():

uint8_t synk_Bound_WL = true;
GAPBondMgr_SetParameter(GAPBOND_AUTO_SYNC_WL, sizeof(uint8_t), &synk_Bound_WL);

, it becomes possible to connect to the device after successful bonding. However, the connection is unstable, sometimes freezing the firmware. When not frozen, it cannot read the characteristics values.

I wonder, if this is a known bug and TI R&D is not working on it. There must be a better way to do this. 

What is suggested to developers in this case? Should they add and remove AL (WL) items manually with HCI_LE_AddWhiteListCmd() and manage their own list? If so, I can follow this approach. I just need guidance to develop a stable design.

Thank you,

Diego V Loss

Reference:

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1460855/not-able-to-connect-in-whitelist-advertisement-when-devices-are-bonded?tisearch=e2e-sitesearch&keymatch=whitelist#

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1519559/cc2651r3-update-cc2651r3-previously-bonded-devices-can-not-connect-in-whitelist-mode?tisearch=e2e-sitesearch&keymatch=whitelist#

  • 0
    TI__Expert 4370 points

    Hello Diego,

    Thank you for reaching out! I discussed this issue with the engineer that originally filed the ticket. This fix should be included in our next SDK release.

    In the meantime, your workaround should be fine. Please let me know if you have any questions regarding implementing it!

    Best Regards,

    Tarek D

  • +1 in reply to Tarek D
    Prodigy 55 points

    Hi Tarek,

    I could be wrong, but I noted that, as the majority of modern mobile equipment makes use of dynamic addresses, the AcceptList (whitelist) is ineffective, as the address must be resolved before being submitted to the list, and resolved again before the list tests it. So it is not effective to refuse one connection before it sees if the central is bonded or not.

    In this way, I adopted the following workaround (that maybe is not a workaround, but the right way to do that, who knows):

    I keep it advertisement filter open for scan and connection for all centrals attempts,

    If my device is in the sync mode, it allows new bondings, otherwyse, it does not.

    Just after it connects (GAP_LINK_ESTABLISHED_EVENT), I submit the resolved and tested address against the bond list, using GAPBondMgr_FindAddr. If it is on the list, I let the connection continue, if it is not, I close the connection immediately with GAP_TerminateLinkReq.

    Again, I don't know if it is the right way to do that. But it's working in a stable way.

    Thank you,

    Diego

  • 0 in reply to D.V.L.
    TI__Expert 4370 points

    Hello Diego,

    That could definitely work! It's perfectly valid to do this, and it will give you your desired behavior, however typically the accept list does not allow the establishment of a connection to begin with. But again, this is a perfectly valid way to do this!

    Best Regards,

    Tarek D