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.

  • Resolved

CC2640R2F: timeout unexpectedly with iPhone (connection instability)

Prodigy 170 points

Replies: 7

Views: 556

Hi all,

When using our customized device (with WiFi(cc3220) + BLE(cc2640) RF coexistence) to have BLE connect to iPhone (iOS 11.x.x), it's really unstable for connection timeout unexpectedly (will receive GAP_LINK_TERMINATED_EVENT from peripheral.c).
I started developing customized BLE application with simple_peripheral example project (simplelink_cc2640r2_sdk_2_20_00_49).
Some info below to see if any hint for troubleshooting:

(1) According to https://developer.apple.com/accessories/Accessory-Design-Guidelines.pdf to modify parameters as following  
// Minimum connection interval (units of 1.25ms, 80=100ms) for automatic parameter update request
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 16
// Maximum connection interval (units of 1.25ms, 800=1000ms) for automatic parameter update request
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 80
// Slave latency to use for automatic parameter update request
#define DEFAULT_DESIRED_SLAVE_LATENCY 1
// Supervision timeout value (units of 10ms, 1000=10s) for automatic parameter update request
#define DEFAULT_DESIRED_CONN_TIMEOUT 550

(2) Checked memory size (heap & task stack = 2048B), and the heapmgrMemMax doesn't exceed total heap size & stack size seems not overflowed after timeout occurred.

(3) Using LiteBlue app to scan and connect to DUT, the timeout still occurred no matter the RSSI range from -1x to -9x

(4) CACHE_AS_RAM is enabled.

(5) The customized image is also tried on CC2640R2F LunchPad , and it still gets timeout unexpectedly after two hours (better than our DUT from 1 min to 30 mins).

(6) The sniffer log by FrontLine:
Capture-2019-04-10_1507_fail-1.zip

  • Hi Jinhua,

    Are both wifi and BLE constantly running?

    Cheers,
    Marie H.

  • In reply to Marie H:

    Hi Marie H.

    Yes, WiFi and BLE are constantly running.
  • In reply to Jinhua Gu:

    Can you point to (and explain) where in the sniffer capture the error occurs?

    Best wishes,
    Tim

    ------------------------------------------------------------------------------------------------------------

    Please be sure to mark the thread as answered if your question was answered :)

  • In reply to Tim C:

    I can't... I am not really familiar with the FrontLine tool (and not good at analyze sniffed log).
    I posted it because my on-site TI supporter recommended me to try it.

    Thanks,
    Jinhua
  • In reply to Jinhua Gu:

    Hi Tim,
    The sniff log what Jinhua attached is very short. Packet#2732, master send the last connection event. However, slave send out advertising at packet #2733. Please advise if you find something.
    Thank you.

    B.R. 

    Jerry

  • In reply to Jerry Kuo:

    Hello. The capture you attached is not decrypted so it is impossible to see what data is being sent when the termination occurs. Is it possible to replicate and capture this without encrypting?

    Also, what is the reason that comes with the GAP_LINK_TERMINATED event? You can check this in gapRole_processGAPMsg() in the GAP_LINK_TERMINATED_EVENT case by inspecting pPkt->reason

    Best wishes,
    Tim

    ------------------------------------------------------------------------------------------------------------

    Please be sure to mark the thread as answered if your question was answered :)

  • In reply to Tim C:

    hi Tim,

    While disconnected, the event from gapRole_processGAPMsg() in the GAP_LINK_TERMINATED_EVENT is

    ===> LL_SUPERVISION_TIMEOUT_TERM


    For this issue, I adopted the workaround from  e2e.ti.com/.../423259

    There it said : "try to run without POWER_SAVINGS defined"
    Therefore I tried to
    Power_setConstraint(PowerCC26XX_SB_DISALLOW);
    Power_setConstraint(PowerCC26XX_IDLE_PD_DISALLOW);
    while BLE connected.

    Then tried to
    Power_releaseConstraint(PowerCC26XX_SB_DISALLOW);
    Power_releaseConstraint(PowerCC26XX_IDLE_PD_DISALLOW);
    While BLE disconnected.

    By this way, the connection instability with iPhone has great improvement.
    My local TI supporter recommended that it may be crystal issue --> Still checking with our HW.


    Thanks,
    Jinhua 

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.