• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 753 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: BLE application using SimpleLink BLE-Stack 2.2.1 disconnect for no apparent reason.

Andrea Treccani
Prodigy 30 points
Part Number: CC2640
Other Parts Discussed in Thread: BLE-STACK,

Hello,
we are working on a CC2640 custom board application using SimpleLink BLE-Stack 2.2.1 (and related toolchain). Code Composer Studio version is: 7.1.0.00016. Our application is derived from "simple_peripheral" example. The problem we are experiencing is the following:

  • After some time (variable in the interval 2min - 10min) we are connected to our peripheral with a Generic BLE Android application (BLE Scanner) connection hangs up for no apparent reason.
  • The peripheral is running normally (no exceptions, or stacks overflows or any "crash" happen) simply decide to restart advertising.
  • It seems that problem doesn't appear if we use similar iPhone generic BLE application (LightBlue).

Tracing the communication this is what we see:

 

  • Initially the peripheral is advertising

 

  • The smartphone require connection and get services.

  • Connection is kept by exchanging Empty PDUs at the required connection interval (min 1600ms, max 1800ms).

  • After some time peripheral stops answering and restart advertising

Have someone encountered similar problem? What could have caused disconnection?
Thank you very much.

  • 0
    TI__Guru** 105180 points
    Hello Andrea,

    Did you measure and set the 32k sleep clock accuracy of your crystal in the app initialization? Marginal sleep clock issues will manifest on longer connection intervals, that could explain the difference in phone OS behaviour. See the HW Troubleshooting article on the TI BLE wiki for more details.

    Best wishes
  • 0 in reply to JXS
    Prodigy 30 points

    Thank you very much JXS,

    it seems you've driven us in the right direction, but we didn't yet solved completely. Some more details of our tests.

    We are using 3 different devices:

    1. iPhone 7 Plus with "LightBlue" app as BLE client.
    2. Samsung SM-G900F Galaxy S5 with "BLE Scanner" app as BLE client.
    3. SONY Xperia Z Ultra with "BLE Scanner" app as BLE client.

    After your suggetion we checked out oscillator accuracy: it is 40ppm on our board (same value of CC2640 default), but for safety we increased the sleep clock accuracy to 200ppm in initialization with the command:

    HCI_EXT_SetSCACmd(200);

    This modification solved the problem for device 2 (it hold connection for 3 hours), but didn't solve for device 3, that stiil loose connection.

    We tried to further encrease oscillator accuracy with the command

    HCI_EXT_SetSCACmd(500);

    But still device 3 loose connection.

    Any other suggestion?

    Thanks.

  • 0 in reply to Andrea Treccani
    Guru 86595 points
    Hi,

    At your board files, make sure you set the correct define that will set the RF Front End and Bias configuration. See, also if using the Connection Control Service might help solve your disconnect issue.

    - kel
  • 0 in reply to Markel Robregado
    Prodigy 30 points

    Hi,

    I've looked at RF front end and bias, they are correctly set for our board:
    #define RF_FE_MODE_AND_BIAS    ( RF_FE_DIFFERENTIAL | RF_FE_INT_BIAS )

    About "Connection Control Service" i don't have such a service in my BLE profile, but I think we can test by modifying connection parameters in code and recompiling. Is that correct?

    We need a slow connection, and we are observing  iOS compliance rules so we set:
    intervalMin: 1600ms
    intervalMax: 1800ms
    slaveLatency: 0
    connSupervisionTimeout: 5600ms

    Are this parameters good for Androis devices also?


    Another detail about disconnection: we put a breakpoint in gapRole_ProcessGAPMsg (peripheral.c). When disconnection happens, we got:

    pMsg->opcode == GAP_LINK_TERMINATED_EVENT
    pPkt->reason == LL_SUPERVISION_TIMEOUT_TERM


    Can this help in undertanding disconnection cause??
    Thank you.

  • 0 in reply to Andrea Treccani
    Guru 86595 points
    Ah, I remember Connection Control Service is for OAD.

    I have experienced disconnection when my code characteristics callback did not queue or post a semaphore/event. Anyway, try more tests at other Android Phones.

    - kel