• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 1343 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.

RTOS/CC2642R: CC2642R update connection parameters fail

Fan huang
Intellectual 430 points

Part Number: CC2642R

Tool/software: TI-RTOS

CC2642 SDK V3.10.00.53 seems with issue on connection parameters updated.

when connected to a Phone BLE4.2/5.0, BLE can update successfully the first time, but will be failed for the second time will never success.

Call function GAP_UpdateLinkParamReq(&req) to updated parameters, the first time  GAP_UpdateLinkParamReq(&req) will return 0x00(OK), and GAP_LINK_PARAM_UPDATE_EVENT will be received soon, and updated SUCCESS

But if again to call GAP_UpdateLinkParamReq(&req) to updated parameters, the second time GAP_UpdateLinkParamReq(&req) will return 0x00(OK), but GAP_LINK_PARAM_UPDATE_EVENT will never be received.

If try to updated again GAP_UpdateLinkParamReq(&req) will return 0x11(bleAlreadyInRequestedMode), and no GAP_LINK_PARAM_UPDATE_EVENT  will be received.

I've tried to add a about 50s' delay, between the first update request and the second, the second update request and  the third, all the update request will be OK, and GAP_LINK_PARAM_UPDATE_EVENT will be received and updated resulut SUCCESS. Once the delay is not enough, GAP_LINK_PARAM_UPDATE_EVENT will not be received, and the next request all will return 0x11(bleAlreadyInRequestedMode) and no GAP_LINK_PARAM_UPDATE_EVENT will be received. 

if failed, no Updated Request can be captured. it seems that BLE do not send it out.

but for another Iphone with BLE V4.1,  the result are quite different.

it seems that a delay is needed between two update request, but the delay is quite less, about 5s is OK. Even continues request update without enough delay, GAP_LINK_PARAM_UPDATE_EVENT always can be received, though FAIL. 

The Process can be captured. BLE will send to 2 kinds of request, LLCP Slave Connection Parameter Request/L2CAP Connection Parameter update Request.

when with enough delay BLE can send LLCP Slave Connection Parameter Request/L2CAP Connection Parameter update Request both.

For Iphone not support LLCP Slave Connection Parameter Request, but support L2CAP Connection Parameter update Request, and will response SUCESS.

When without enough delay BLE only send out LLCP Slave Connection Parameter Request, but Iphone not support so failed.

  • 0
    TI__Guru 57865 points

    Hi Fan,

    Assigning an expert to take a look at this.

  • 0 in reply to J Lindh
    TI__Mastermind 23440 points

    Hi Fan,

    This is interesting. Can you reproduce this with eg. two launchpads and SDK examples (with some changes)? It would make it easier to get to the bottom of what is happening, and rule out effects from your own application.

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    Intellectual 430 points

    Hi Aslak,

    I'd tried in my BLE module and to confirm this issue i rnn the demo simpleperipheral,  with tiny change to trigger the request, the result is the same.

    Of course, you can try with the demo to confirm this.

    I used to use CC2640R2 SDK V1.40. 00.45, without such issue like this.

  • 0 in reply to Fan huang
    TI__Mastermind 23440 points

    Hi Fan,

    Thanks! Can you share exactly how to reproduce?

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    Intellectual 430 points

    Aslak,

     you can add SimplePeripheral_processParamUpdate to 

    static void SimplePeripheral_performPeriodicTask(void)

    {

    if (connected){

    SimplePeripheral_processParamUpdate()

    }

    }

    and enable  and start clkPeriodic in static void SimplePeripheral_init(void)

    // Create one-shot clock for internal periodic events.
    Util_constructClock(&clkPeriodic, SimplePeripheral_clockHandler,
    SP_PERIODIC_EVT_PERIOD, 6000, false, (UArg)&argPeriodic);

    Util_startClock(&clkPeriodic)

    you can change the period and capture the process. To be more clear, suggest change connection parameters in SimplePeripheral_processParamUpdate every time.

    if successful, GAP_LINK_PARAM_UPDATE_EVENT will be received in 

    static void SimplePeripheral_processGapMessage(gapEventHdr_t *pMsg)

    case GAP_UPDATE_LINK_PARAM_REQ_EVENT:
    {

    }

  • 0 in reply to Fan huang
    TI__Mastermind 23440 points

    Hi Fan,

    Thank you. I will try to reproduce and create a bug report for our development team.

    In the mean time, have you found any way to work consistently around the issue?

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    TI__Mastermind 23440 points

    Hi,

    I could reproduce what you saw. It turns out that in the 5.0 specification, Volume 3, Section C, Chapter 9.3.9.2 there is a paragraph saying that we're not allowed to send a new L2CAP Connection Parameter Update Request within 30 seconds of receiving a Connection Parameter Update Response. Strange as it may seem, this is expected behavior.

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    Intellectual 430 points

    Hi Aslak,

    I found what you mentioned TGAP(conn_param_timeout) in core SPEC 5.0.

    The sad truth was that once BLE request to update connection parameters within 30s, SDK will not trigger the result event any more. No chance to update it again unless disconnection and connection again. what's more, the timeout could be more then 30s, seems at least 50s.

     

    I don't know why there is so much difference between cc2640R2 and cc2642.

    I used to use cc2630R2 simplelink_cc2640r2_sdk_1_40_00_45 ble5stack, there is no such issue.