• State TI Thinks Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 1314 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.

CC2642R: CC2642R update connection parameters fail if parameters is the same as previous.

Fan huang
Intellectual 420 points
Part Number: CC2642R
Other Parts Discussed in Thread: BLE-STACK

CC2642R with SDK 3.10.00.53

function to require to update connection parameters as below:

static void SimplePeripheral_processParamUpdate(uint16_t connHandle,
uint16_t desiredMinInterval,
uint16_t desiredMaxInterval,
uint16_t desiredSlaveLatency,
uint16_t desiredConnTimeout)
{
gapUpdateLinkParamReq_t req;
uint8_t connIndex;

req.connectionHandle = connHandle;
req.connLatency = desiredSlaveLatency;
req.connTimeout = desiredConnTimeout;
req.intervalMin = desiredMinInterval;
req.intervalMax = desiredMaxInterval;

connIndex = SimplePeripheral_getConnIndex(connHandle);

SIMPLEPERIPHERAL_ASSERT(connIndex < MAX_NUM_BLE_CONNS);

Clock_Struct* pUpdateClock = connList[connIndex].pUpdateClock;
if( pUpdateClock != NULL ){
// Deconstruct the clock object
Clock_destruct(connList[connIndex].pUpdateClock);
// Free clock struct
ICall_free(connList[connIndex].pUpdateClock);
connList[connIndex].pUpdateClock = NULL;
}

// Send parameter update
bStatus_t status = GAP_UpdateLinkParamReq(&req);

#ifdef STATUS_PRINT
char printdata[40]={0};
sprintf(printdata, "\r\ncParaReq %d %d %d %d %d %d", req.intervalMin,req.intervalMax,req.connLatency,req.connTimeout,connIndex,status);
PRINT_STATUS((uint8_t*)printdata, strlen(printdata));
#endif

// If there is an ongoing update, queue this for when the udpate completes
if (status == bleAlreadyInRequestedMode)
{
// spConnHandleEntry_t *connHandleEntry = ICall_malloc(sizeof(spConnHandleEntry_t));
// if (connHandleEntry)
// {
// connHandleEntry->connHandle = connHandle;
//
// List_put(&paramUpdateList, (List_Elem *)&connHandleEntry);
// }
}
}

Event in static void SimplePeripheral_processGapMessage(gapEventHdr_t *pMsg)

case GAP_LINK_PARAM_UPDATE_EVENT:
{
gapLinkUpdateEvent_t *pPkt = (gapLinkUpdateEvent_t *)pMsg;

// Get the address from the connection handle
linkDBInfo_t linkInfo;
linkDB_GetInfo(pPkt->connectionHandle, &linkInfo);


if(pPkt->status == SUCCESS)
{
connection_info.latency = linkInfo.connLatency;
connection_info.connTimeout = linkInfo.connTimeout;
connection_info.connInterval = linkInfo.connInterval;

#ifdef STATUS_PRINT
char printdata[40]={0};
sprintf(printdata, "\r\ncParaupdate %d %d %d", connection_info.connInterval, connection_info.latency, connection_info.connTimeout);
PRINT_STATUS((uint8_t*)printdata, strlen(printdata));
#endif
}
else
{
#ifdef STATUS_PRINT
//print status
PRINT_STATUS("\r\nParaupdate fail", 17);
#endif
}

if the parameters are different, function GAP_UpdateLinkParamReq() will return 0(success) and will trigger GAP_LINK_PARAM_UPDATE_EVENT

but if the parameters is the same as previous one, function GAP_UpdateLinkParamReq() will return 0(success), but no GAP_LINK_PARAM_UPDATE_EVENT,

then again to update parameters, function GAP_UpdateLinkParamReq() will return 17(bleAlreadyInRequestedMode), no GAP_LINK_PARAM_UPDATE_EVENT,

then any requirement to update, function GAP_UpdateLinkParamReq() will always return 17(bleAlreadyInRequestedMode), no GAP_LINK_PARAM_UPDATE_EVENT.

Disconnect and re-connect can recover it, but it doesn't  make sense.

BTW, in initiate I changed the timeout to the minimum with GAP_SetParamValue(GAP_PARAM_CONN_PARAM_TIMEOUT, 1), or the GAP_UpdateLinkParamReq()  will be failed if too often.

the debug log as below:

  • 0
    TI__Guru* 81801 points

    Hi Fan,

    Why do you need to send two connection parameter update requests with the same parameters after one another? (If the first request is rejected by the peer device, the BLE-Stack will take note and you will not be able to send more requests with these parameters.)

    What version of the SimpleLink CC13x2/CC26x2 SDK are you using?

    Is your device the master or the slave in the connection?

  • 0 in reply to Marie H
    Intellectual 420 points

    Hi Marie H,

    I was testing the connection parameter update function and find such issue.

    SDK version  is 3.10.00.53.

    My device is a slave and provided user an interface to update connection parameters for power control.

    From the captured log, the second update request was send out successfully and accepted by master, but the no GAP_LINK_PARAM_UPDATE_EVENT. This could be a bug. The bad result is no chance to update connection parameter any more if not cut off the connection

     

  • 0 in reply to Fan huang
    TI__Guru* 81801 points

    Hi Fan,

    1. Can you check if you are receiving a HCI event with opCode HCI_LE_CONNECTION_UPDATE and check the status of this one? (E.g. in SimplePeripheral_processStackMsg(), in the HCI_COMMAND_STATUS_EVENT_CODE case, check for HCI_LE_CONNECTION_UPDATE opcode.)

    2. Can you post the log file? (I would like to compare the LL Connection Update packets.)

  • 0 in reply to Marie H
    Intellectual 420 points

    Hi Marie H,

    I've add debug message in SimplePeripheral_processStackMsg(), when the issue happens, there is no any event in stack message.

    the log as below:

  • 0 in reply to Fan huang
    TI__Guru* 81801 points

    Hi Fan,

    Can you post the log file? (I would like to compare the LL Connection Update packets.)

  • 0 in reply to Marie H
    Prodigy 96 points

    Hi Marie H,

    This is the log file.https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/log1.7z

  • 0 in reply to Sage Zhu
    TI__Guru* 81801 points

    Thanks Sage, Fan,

    This is expected behavior. When the only update is in the transmit window offset there is no reason for the controller to tell the host, and thus there is no event passed from the host to the application.

  • 0 in reply to Marie H
    Intellectual 420 points

    Hi Marie H,

    No Event is OK for the same parameters, but the sad truth is this will cause connection parameter mechanism dead. After the second requirement with the same parameters,  GAP_UpdateLinkParamReq() will always return 17(bleAlreadyInRequestedMode), EVEN change the value. This should be unexpected and unacceptable.

  • 0 in reply to Fan huang
    TI__Guru* 81801 points

    Hi Fan,

    Sorry for the late reply.

    I'm sorry, I am not able to reproduce what you are describing.

    Did you test with LL connection parameter update request instead? (Any reason why you wanted to use L2CAP connection parameter update request?)

  • 0 in reply to Marie H
    Intellectual 420 points

    Hi Marie H,

    Can you explain more detail on how you implement the function? Can you provide the return code for  GAP_UpdateLinkParamReq()  and the corresponding event , and the log file?

    note: example code will put the parameter update task in a list if a update task is in process. when the issue happens, all the following update requests will be put into list first. 

    Please note that both LL connection parameter update and L2CAP  connection parameter update are used to request when GAP_UpdateLinkParamReq() was called.

  • 0 in reply to Fan huang
    TI__Guru* 81801 points

    Hi Fan,

    I used Project Zero and sent a GAP_UpdateLinkParamReq() each time I pressed the left button. However I was not able to find a master device that does not support LL connection parameter update request. 

    I tried using your example code but I got lots of compilation errors since you have only provided code snippets. 

  • 0 in reply to Marie H
    Intellectual 420 points

    Hi Marie,

    Your test procedure should be enough to find out the issue. A master,  support  LL connection parameter update request or not, will not affect the result, I've tested both.

    Please print out the return code of GAP_UpdateLinkParamReq()  each time you pressed the left button, and print out the event status of GAP_LINK_PARAM_UPDATE_EVENT in SimplePeripheral_processGapMessage

  • 0 in reply to Fan huang
    TI__Guru* 81801 points

    Hi Fan,

    I just tested again. As you say, when sending multiple GAP_UpdateLinkParamReq() commands with the same parameters I get the 0x11 bleAlreadyInRequestedMode error. However if I change the parameters I am able to send multiple GAP_UpdateLinkParamReq() in the same connection.

  • 0 in reply to Marie H
    Intellectual 420 points

    Hi Marie,

    Great, you can reproduce the issue I faced.

    In the same connection, once 0x11 bleAlreadyInRequestedMode was got, all the following request will be with the same 0x11 error, even parameters was changed. 

    This should be a bug and with high potential risk in my application. For in my application, parameter was used to control the power consumption while our application is especially sensitive to power. If the parameter cannot be updated, the power consumption and data transmission cycle will be out of control.

    Or there is was an interface I can use to cancel the previous request if 0x11 was returned, so that I have the chance to request update in the same connection. Though it is not the fundamental solution.

    BTW, we used to use CC2640R2 SDK 1.40.00.45 without such issue.

  • 0 in reply to Fan huang
    TI__Guru* 81801 points

    Hi Fan,

    I am not able to reproduce the situation where following requests with new parameters are rejected.

    Can you send me a minimal example and steps to reproduce this situation?

  • 0 in reply to Marie H
    Intellectual 420 points

    Hi Marie,

    You mean in the same connection,  after sending multiple  GAP_UpdateLinkParamReq(), returen 0x11, then change to new parameters the return code could be recover to 0x00(SUCCESS) again and with event GAP_LINK_PARAM_UPDATE_EVENT?

     If so, that should be perfect. could be please provide the code file changed based on example?

    In my project, the code and steps of the update request is as I described on the first page, but the result is different as yours. I will compare what's the difference.

  • 0 in reply to Fan huang
    TI__Guru* 81801 points

    Hi Fan, 

    When I send GAP_UpdateLinkParamReq() with a new value each time I always get success. When I send first GAP_UpdateLinkParamReq() with the same parameters a couple of times and then change the parameters I can not get a success status anymore. I have filed this as a bug.

    As a work-around I would suggest:

    a) Always change the parameters after sending a GAP_UpdateLinkParamReq(), even if it's just a small change.

    b) Terminate and re-establish the connection if you get the 0x11 fail status.