• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 52 subscribers
  • Views 517 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.

CC2640R2F: CC2640 reconnect after bonding issue

Alexander
Prodigy 70 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: LAUNCHXL-CC2640R2

Hello,

my Launchxl-cc2640r2 development board with custom firmware based on ble5stack project-zero has a connection issue. I can connect to it with Passkey pairing method and the bonding data is stored correctly.

But when I disconnect from the device and try to reconnect with the same device it fails.

Interestingly it works when I reset the Launchxl after the initial connection. No pairing is needed and it uses the stored bonding data.

And connecting other devices also works without the need for reset.

Do you have any idea where this issue might come from?

regards
Alex

Sniffer_Logs.zip

  • 0
    TI__Guru** 101460 points

    Hi Alex,

    Thank you for reaching out and thank you for the details provided.

    Could you please specify which SDK version you are using?

    Looking at the traces provided, it looks like the advertiser does not answer any of the connection events when the central tries to reconnect.

    It may be interesting to see if the BLEStack posts the event GAP_LINK_ESTABLISHED_EVENT.

    Best regards,

  • 0 in reply to Clément
    Prodigy 70 points

    Hi Clement,

    I am using SDK version 4.40.00.10.

    GAP_LINK_ESTABLISHED_EVENT and all other events are not triggered when connection request fails. That's why I have no idea where to look for the issue.

    regards

    Alex

  • 0 in reply to Alexander
    TI__Mastermind 25810 points

    Hey Alex,

    A good first step here would be: can you reproduce this issue with an unmodified project_zero or simple_peripheral? This will help us set a baseline for our debugging.

    By the way, thanks for providing the sniffer logs. I do see the same as my colleague, there is no response to the connection indication packet.

  • 0 in reply to Ammar N
    Prodigy 70 points

    Hi Ammar,

    I am currently working on reproducing the issue with a minimal project_zero example. Unfortunately the minimal example is working as expected. I need to find out what I messed up in my project, but the changes are quite a lot. Doing a complete diff between the projects and testing all changes will take me several days. Can you please help me, by giving some tips on where to start looking for the issue?

    regards

    Alex

  • 0 in reply to Alexander
    TI__Mastermind 25810 points

    Hey Alex,

    I would start debugging by watching the heap (see Debugging Common Heap Issues) to see there is any issue with running out of heap. Does the device continue to advertise after the failed second connection? You'll want to rule out if the device is asserting entirely or if this is just a connection (or perhaps reconnection) issue.

    You mention using ble5stack on the CC2640R2, so there is a chance this is a memory issue. Let's start here.

  • 0 in reply to Ammar N
    Prodigy 70 points

    Hi Ammar,

    the device continues to advertise and I can pair new devices as well. What I noticed yesterday is that the tests fail when I use a specific MAC address. It seems like the device is ignoring requests from certain MAC addresses:

    For example the address 0C:88:2A:11:11:03 is not working. If I change to 0C:88:2A:11:12:03 all my connection tests pass.

    But according to this article I can use any MAC if it is declared as public: Bluetooth Addresses & Privacy in Bluetooth Low Energy - Novel Bits

    Is there any filter that blocks certain MAC addresses? Maybe based on failed connection requests?

    regards

    Alex

  • 0 in reply to Alexander
    TI__Mastermind 25810 points

    Hey Alex,

    Interesting observation. Do you have a sniffer log of the failed connection attempt after the device bonds? I would like to know the error code the device sends when you attempt to reconnect. As far as I know, the device should be able to resolve the address once pairing/bonding is enabled. Is the central device you are pairing to configured with RPAs enabled (if it's a smartphone, then this answer is most likely a yes)?

    The only other filtering that would block requests from other MAC addresses is with regards to accept/reject lists (formerly known as whitelists). Are these enabled at the application?