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.

CC2640: Central role consistently dropping connections after 17 minutes due to supervision time-out

Part Number: CC2640

Hello

I would like to share the following scenario in case someone else may have already experienced something similar or if a possible idea may be contributed to solve this issue.

We are using stack version 2.02.00.31 with our CC2640 chipset on a customized board with the multi role files as the project template. We have paring and encryption enabled using OOB data and we successfully connect as a central with another of our devices acting in peripheral role. When our device is connected in central role, we have our advertising disabled so we can just keep one single connection established at a time.

Once a connection is established and authenticated, we execute a connection parameters update using 2000ms for connection interval and a supervision time-out of 7000ms with a slave latency of 0. Then we measure how long the connection lasts and we are consistently observing that after 17.5 minutes later (average) the connection always breaks due to supervision time-out error.

It gets our attention how consistent this 17 minutes value is. We have measured dozens of repeated connections at the same distance (3 feet between central and peripheral devices) with undisturbed devices overnight.

Then we conducted a test with our peripheral device connecting with another product using a different hardware and chipset acting as a central and we don't have this problem. We have obtained stable connections for more than 3 hours (after several iterations in a row) and the link remains stable. This has allowed us to isolate the condition to our device with the CC2640 chipset acting in central role,

Do you have some suggestions/comments/ideas about how to improve the connections in our CC2640-based product acting in central role? It appears as if we have a synchronization issue of some sort.

  • Hi,

    This usually points to a hardware issue, have you checked the frequency of your slow clock? Do you see the same 17min with faster connection interval?

    Best wishes
  • Hi Zahid,

    We conducted a test with an interval connection of 100ms instead of 2000ms and observed the same behavior of disconnections in about the same time (17 min). 

    We still have to check on the frequency of the slow clock for consistency. 

  • Hi Ricardo,

    What you are seeing could be related to this :
    e2e.ti.com/.../574277

    I sent you a PM with the patching instructions
  • Hi Christin,

    We are working on the migrating to the BLE 2.2.1 stack version for later implementation of the patch as per the provided instructions (thanks also to Zahid for the reply). As soon as we complete our testing I will update this thread with the results.

    Thanks for your support.

    Regards

    Ricardo Bello

  • Update 03/02/2017

    Yesterday we completed the migration to the BLE Stack version 2.2.1 and confirmed that the issue was still observed as mentioned in the patch documentation.

    Then we proceeded to apply the patch files over the BLE Stack 2.2.1 files as required by the patch documentation and after some full clean up (deletion) of every output file and rebuilding of the stack and app projects again from scratch, we have confirmed the disconnection issue after 17.5 min is no longer observed. We have measured connections lasting for more than 40 minutes now.

    We are still doing some more tests checking how long the connection will last after the patch if the units are not disturbed, but so far this is a very obvious change in the behavior after applying this patch. We are also in the middle of checking for no unexpected side-effects but so far our current BLE 4.2 features (pairing, OOB data checking, encryption) are working as expected.

    Update 03/03/2017

    We conducted an overnight test and our devices were connected for 14.5 hours until we manually executed a disconnection.


    Thanks for the provided support.

    Ricardo Bello