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.

BLE stack dropping connections

Other Parts Discussed in Thread: CC2541, CC2640

Hi,

I am working with a cc2541 running as a peripheral.

I have a piece of code that causes the ble stack to drop connections once it runs. Once the connection has been dropped I cannot reconnect to the device without power cycling, although it still advertises.

I assume the dropped connection is because my code is taking too long and blocking the ble stack from maintaining the connection.

My questions are:

  • Is there some way I can run my code while maintaining a connection?
  • Why can the device not be connected to after dropping the connection and is it possible to reconnect without power cycling?

It might be worth mentioning that the code also prevents any connections once it runs during advertising. I managed to work around that by turning advertising off before my code and turning it back on afterwards.

Any advice would be appreciated. 

Thanks,

Daniel

  • As it appears you have discovered, the CC254x device does not use an RTOS or any type of preemptive OS. So yes, if you hog the processor for too long, you will throw off the timing of the stack and cause the connection to drop. The stack should recover gracefully assuming you are using BLE 1.4.2 (www.ti.com/blestack). If it doesn't, your application must be causing some other issue. I would start debugging this by logging all of the GAP events and statuses that are returned from the GAPRole (peripheral.c). Then analyze these to see if they make sense or where the problem is.

    Of course you could avoid all this by using the CC2640 which uses an RTOS. In this case, your application could freely process as long as it desires.
  • Hi Tim,

    I am using stack 1.4.1 so that might be why I'm unable to reconnect after a dropped connection. I will upgrade to 1.4.2 to see if that resolves the issue.

    Also, is it at all possible to run my code that hogs the CPU for some time and still maintain a connection?

    Thanks,
    Daniel
  • Basically, you need to ensure that you allow the controller to process every connection interval - 5 ms. So you have a couple options:
    1. increase your connection interval such that it is longer than the longest time your application will ever process for
    2. cease application processing somehow to allow the controller to process. perhaps use a hardware timer to interrupt your application for it to stop processing
    3. split your application processing into determinate length chunks of time and synchronize these using the connection event callback (configured with HCI_EXT_ConnEventNoticeCmd)
    4. use the cc2640! It really would solve all your problems ;)