• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 1073 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.

Private addresses cause immediate disconnection

Peter Borenstein
Mastermind 8695 points

Other Parts Discussed in Thread: CC2541

My peripheral devices disconnect immediately after forming a connection. This is caused by trying to look up the identity resolving keys (IRK) for private MAC addresses.  I have an iOS and and Android app, and this problem only occurs on iOS. The important difference is that iOS uses a private address type, and Android is public. By commenting out gapBondMgrResolvePrivateAddr in gapbondmgr.c, the connection problem no longer occurs. The problem only happens when I write to OSAL SNV many times. My devices occasionally update 3 variables that I want backed up in nonvolatile memory.  They are updated rarely, but to recreate the problem I accelerated all activities and the problem does not occurs without backing these variables up. My theory is that gapBondMgrResolvePrivateAddr spends too much time sorting through OSAL SNV for the IRKs and it misses packets. 

The problem goes away after a few days. The OSAL  SNV will clean itself up by moving all saved items to a new page.  This speeds up gapBondMgrResolvePrivateAddr and connections can be made (I assume). 

Connections do form consistently. The perpheral state notification callback is triggered, and the new state is GAPROLE_CONNECTED. I make an LED blink when this happens. I can see on the packet sniffer that the slave only responds with one packet in the connection.

My devices do not use saved IRKs (that I know of). Is it safe to comment out gapBondMgrResolvePrivateAddr in GAPBondMgr_ResolveAddr?

I am using a CC2541

  • 0 in reply to Peter Borenstein
    TI__Guru** 105180 points

    Hello Peter,


    If you are doing an OSAL SNV write during a connection, there exists the possibility that the flash compaction (copy/erase) may occur. If this occurs during the connection, the BLE timing may be violated and the connection could drop. Are you doing writes during the connection? If so, I would try to schedule the writes outside of the connection, or perform the flash compaction outside of a connection (preferred).

    See this thread for tips on resolving private resolvable addresses (PRAs) during a connection: e2e.ti.com/.../1431234


    Note that Android 5.0 uses PRAs.


    Best wishes

  • 0 in reply to JXS
    Mastermind 8695 points

    Hi JXS,

    I did not write this code, it is located in gapbondmgr.c. The function searches for GAP_BONDINGS_MAX keys in OSAL SNV. It is the multiple key searches in a congested OSAL SNV that ruins the connection. There is no copy/erase.

    I noticed your example used GAPBondMgr_ResolveAddr instead of GAP_ResolvePrivateAddr. How does GAPBondMgr_ResolveAddr look up the IRKs to resolve the PRA? Are these redundant functions?