CC2640R2F: Pairing Issue: CC2640R2 based TI central and peripheral devices are not able to pair successfully

Hi Amod,

Error code 8 is "Connection timeout" per the Bluetooth SIG spec version 4.2 Vol2 Part D Error Codes. If you had put a breakpoint at the pairing state started event, this could have caused a delay (because the code halted) which causes the connection to time out. Were you using breakpoints when you did your test? 

I did this test with multi-role but did not encounter an issue:

1. I opened two instances of CCS in two separate workspaces, one for the "central" and one for the "peripheral".

2. I imported the multi_role_CC2640r2lp_app into each workspace. I modified each to have the different pairing settings from your initial post (e.g. keyboard only).

3. I loaded each project onto a different CC2640R2 Launchpad

4. On the device that I loaded with the initiator code, we are having that be the peripheral. I opened the serial port with putty and using the buttons navigated the menu to advertise

5. At the same time, on the device that I loaded with the central/wait for req code, I opened the serial port with putty and using the buttons navigated the menu to scan. Then I selected Connect and chose the address for my other device.

6. When I did all this, the connection succeeded and pairing and bonding succeeded, no issues. See screen captures below:

Peripheral:

Central:

If you use the off-the-shelf multi-role example with only the pairing/bonding parameter modification as discussed, and follow these steps to test (with no breakpoints set), do you see the error code or do you see a successful pairing as shown in my test?

Regards,

Katie

Katie,
thank you for trying out the tests for us.

We had tested the 'multi-role' example (off-the-shelf) at our end and observed successful pairing.
That's how we could conclude the ideal chain of pairing events at the central.

To answer your question about breakpoints; we are not using any breakpoints, rather we utilise the 'debug UART' for printing out debug data via COM port.

Regarding the connection timeout (Error code 8) issue you pointed to, I can't understand why would that be the case.
Let me explain the reasons supporting that:

1. Before our central pairs with the peripheral, the connection between the two is established and the MTU size is exchanged.
2. Our central reports pairing failed (without even reporting the pairing has started). This is the issue we are discussing.
3. Then our central initiates service&characteristics discovery of the peripheral, which goes on as expected.
4. Later on, notifications of certain characteristics are subscribed and the peripheral pushes those periodically.

During all the above activity, the connection is never discontinued or re-attempted, even though the pairing fails (this itself is strange!!).

One more thing, on the lines of a possible timeout; our custom BLE code has several other modules that reside above the 'TI BLE stack', which are responsible for taking decision based on the stack events. The data flow while pairing is described below:
When any pairing event is received in the 'multi.c' file, it is routed to our event dispatcher (via a function call). Subsequently , the event is further escalated to our event handler(via a function call) that acts accordingly and directly communicates with the 'multi.c' file.

Given that there is a 30 seconds timeout for entering the pairing key, these negligible delays (due to our data routing) should not result in pairing failure.
Also, as the pairing start event is never generated at the central (directly a failure is reported), timeout due to our data routing, could not be the culprit.
Additionally, the peripheral device which has the same modular hierarchy, works as expected with nRF app (BLE central mode) and also with BTool.

Something that stands out here is, why is the 'pairing started' and 'passkey needed' events not generated at the central end?

We were able to sniff the BLE connection using the TI CC2540 Dongle and attached here are '*.psd' files.

The "Passed pairing(p.ours+c.multi).psd" shows the communication between our custom peripheral and TI multi role central. We have modified pairing configuration in central and disabled service discovery. You would find the data exchange after connection from packet number 142. Here the pairing was successful.

The "Failed pairing(p.ours+c.ours).psd" shows the communication between our custom peripheral and our custom central. Here the pairing failed . You would find the data exchange after connection from packet number 44. We had also disable our debug UART prints while capturing this communication.

After comparison of two logs, the communication seems almost similar (related to pairing) yet the pairing fails while using our central device.

Are there any differences that stand out from the logs? Let us know.

Failed pairing(p.ours+c.ours).psd

Passed pairing(p.ours+c.multi).psd

Katie,

The error code 8 symbolising "unspecified reason" fits better.  I was able to trace this error code in "gapbondmgr.h" file, where it is represented as "SMP_PAIRING_FAILED_UNSPECIFIED".

I tried to measure the heap usage of our software, but was unable to effectively analyse.

Initially , I utilised the ROV plug-in provided with CCS v7. Here, a graph of our code's stack usage was available but that of heap memory usage was not generated. Please see below the pictorial representation.

Could you guide us on how to view the the heap details using ROV. Are there any modifications required in code?

Also, while looking into our code, related to heap settings, I found that our code is configured for auto-size heap.

That is, HEAPMGR_CONFIG --> 0x80 and HEAPMGR_SIZE --> 0x0.

Below are the details on what HEAPMGR_CONFIG  signifies for its various configurations, as available in the "app_ble.cfg" file:

* The heap manager to use is selected by setting  HEAPMGR_CONFIG to the corresponding value (see below)

* 0    = osal Heap manager, size is static.

* 0x80 = osal Heap manager, with auto-size: The remaining RAM (not used by the system) will be fully assign to the Heap.

* 1    = HeapMem with Static size

* 0x81 = HeapMem with auto-size. The remainning RAM (not used by the system) will be fully assign to the Heap.

* 2    = HeapTrack (with HeapMem) with fixe size

* 0x82 = HeapTrack (with HeapMem) with auto-size: The remainning RAM (not used by the system) will be fully assign to the Heap.

As per the above information, while heap is auto-sized, the remaining RAM is fully utilised as heap.

Our software currently utilizes 70% of RAM out of the ~17KB available in CC2640R2.

This leaves us with 5KB of heap, wouldn't this be more than sufficient for smooth operation?

Thanks and Regards.

Hi Amod,

Especially with multi-role and pairing/bonding, I think 5KB could actually not be enough. Can you try enabling heap manager metrics as described here to try to find if you are running out of heap: dev.ti.com/.../ble-common_heap.html You have to follow these steps to enable the heap tracking. For OSAL heap, this is the way to debug, not ROV - that is not displaying OSAL heap.

Regards,
Katie

Hi Amod,

I'm so glad that you were able to resolve your issue and thanks a lot for posting the process and solution you came up with - it can be helpful for us and others going forward. Thanks again!

Regards,

Katie