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

Frequent "instant passed" disconnections using BLE Stack 2.2.0.18 on CC2650 Launchpads

Dave Beal
Intellectual 880 points
Other Parts Discussed in Thread: CC2650

I am running TI BLE Stack 2.2.0.18 on two CC2650 Launchpads.  One is running an app derived from the simple_peripheral example project; the other is running an app based on simple_central.  No changes have been made to the Stack code on either.  I'm using Code Composer Studio 6.2.0.50.

I'm seeing frequent disconnections between the two devices.  The error code is usually LL_STATUS_ERROR_INSTANT_PASSED (0x28), although I sometimes get LL_STATUS_ERROR_CONNECTION_TIMEOUT (0x08), and LL_STATUS_ERROR_CONN_FAILED_TO_BE_ESTABLISHED (0x3E).  The 0x28 errors always occur during a Connection Parameter Update.  If the connection survives past the Connection Parameter Update and the Exchange MTU Request, it seems to be reliable and is able to repeatedly transfer attribute values.  The devices are sitting within inches of each other on my desktop.  I've done a lot of trial and error to see if the behavior of the app influences the frequency of the connection failures (like doing explicit Conn Param Updates), but have gotten no consistent results.

I found other reports of "instant passed" errors on the forum, but they were from May 2013 and all appeared to involve iPhones.  Has anyone seen this behavior recently between two TI CC2650s running BLE Stack 2.2?   Thanks!

  • 0
    TI__Genius 12815 points
    Hi Dave,

    You mention that these apps are based on simple_peripheral and simple_central. Can you give some details about what changes were made?

    Do you have a sniffer capture of this behavior taking place?
  • 0 in reply to RachelP
    Intellectual 880 points

    Hi Rachel -

    Thanks for the quick response.  A TI Packet Sniffer trace of the 0x28 failure is below.  The changes I have made to simple_peripheral are mostly just changing the attribute table, and enhancing the notification code in case the attribute value being notified is too big to fit in the notification.  The simple_central was modified to discover the peripheral's specific attributes, register for notification on one of them and then to repeatedly read and write a couple attributes. Most of the code I've added to both roles hasn't even been executed yet when the connection fails. I have made no changes to underlying things like task priorities, nor have I altered any interrupt-time code.

  • 0 in reply to Dave Beal
    TI__Genius 12815 points
    Hi Dave,

    Can you attach the full sniffer capture?
  • 0 in reply to Dave Beal
    Intellectual 880 points
    Hi Rachel -
    Note the missing connection events in the above trace. The connection interval is 100 msec, but packets 85 and 87 show delays of 499 and 2000 msec. I think my master (modified simple_central) is broken, maybe because simple_central was written for the CC2650 Smart RF06 Dev Kit, and I'm running it on a CC2650 Launchpad. I thought that all I had to do to make simple_central run on the Launchpad was to add "--define=CC2650_LAUNCHXL" to the compiler flags of the Stack and App projects, but maybe there's more to it.
  • 0 in reply to Dave Beal
    Intellectual 880 points

    I think this problem is fixed.  The problem apparently was that the simple_central code assumes that it has an LCD display, which exists on the CC2650 Smart RF06 eval kit but not on my CC2650 Launchpad.  Trying to write debug messages to the non-existent display disrupted timing enough to make the Master miss multiple consecutive connection events, which caused connection failure.

    The fix was to add "#define Display_DISABLE_ALL 1" to the top of the Drivers/Display/Display.h file in TI-RTOS.

    Thanks to Rachel and Tom Kopriva, who responded in a different forum thread!