Connection Interval Update

Other Parts Discussed in Thread: CC2640

Hi All,

First of all, I know I posted this before but I did not get any more answers and I really need to get this right. ( https://e2e.ti.com/support/wireless_connectivity/bluetooth_low_energy/f/538/t/491894 )

I am using the SimpleBLECentral project connected to the SimpleBLEPeripheral (CC2650DK). I have set DEFAULT_ENABLE_UPDATE_REQUEST to FALSE on the central device and to TRUE on the Peripheral. I know that at a time equal to DEFAULT_CONN_PAUSE_PERIPHERAL after the connection has been stablished, the peripheral device will send a connection parameter update request to the central device.

The result of this update request is shown on the LCD:

SimpleBLECentral_processRoleEvent(gapCentralRoleEvent_t *pEvent){

switch (pEvent->gap.opcode){

....

case GAP_LINK_PARAM_UPDATE_EVENT:

{

LCD_WRITE_STRING_VALUE("Param Update:", pEvent->linkUpdate.status,10, LCD_PAGE2);

}

...

}

My question is: Which are the possible values for pEvent->linkUpdate.status?

Sometimes I get 0 on the LCD, other times I get 105 and some others 240. I tried to understand by myself where the status is set, but i did not succeed.

In synthesis, I want to know:

1 - Where, in the code of the central device, the status is set after reception of the update request from the peripheral.

2 - Which are the possible values for pEvent->linkUpdate.status

As suggested by Sean2, I read the bcomdef.h file but non of the values I see on the screen are among the possible values defined for bStatus_t defined there.

I get 105, 20, 47 and other values when using the default out-of-the box projects (central and peripheral). I would like to understand the meaning of these status values and the reason why I get so many different results when I am using the hex files provided when installing the BLE stack.

I apologize once more for posting this again but I waited over a week and, as I said before, I really need this information.

Thanks,

Daniel

over 9 years ago

0 Tim C over 9 years ago

TI__Mastermind 34660 points

Hello. We have tried to capture return values in the SDG (www.ti.com/.../swru393) but it appears these are missing. I'll add them into the next version. In the meantime:

1. This is set in the library code so you can not see it.
2. The possible values are:
HCI_SUCCESS (0x00): connection updated sucesfully
LL_STATUS_ERROR_BAD_PARAMETER (0x12): invalid range for a connection parameter
LL_STATUS_ERROR_ILLEGAL_PARAM_COMBINATION (0x12): invalid combination of connection parameters
LL_STATUS_ERROR_INACTIVE_CONNECTION (0x02): connection is not active
LL_STATUS_ERROR_CTRL_PROC_ALREADY_ACTIVE (0x3A): parameter update is already in progress
LL_STATUS_ERROR_UNACCEPTABLE_CONN_INTERVAL (0x3B): if not using 4.1 mast/slave feature, the requested connection interval must be a multiple/divisor of all other active connection intervals and must not less than the allowed maximum connection interval as determined by the maximum number of allowed connections times the number of slots per connection (8)
The above values don't relate to you since they cover the case of the master attempting to send the connection request. The following values are possible to result in an attempt from a slave but only when the you (the master) have implemented 4.1 master/slave features (CTRL_V41_CONFIG) in the buildConfig.opt file and the slave is using the 4.1 connection update method. I'm assuming this is what you are doing.
HCI_ERROR_CODE_UNSUPPORTED_REMOTE_FEATURE (0x1A): connection param request 4.1 feature or Reject Indication Extended feature was not included in feature exchange
LL_STATUS_ERROR_INVALID_PARAMS (0x1E): invalid parameters from slave
LL_STATUS_ERROR_TRANSACTION_COLLISION (0x23): a connection parameter request procedure is already pending or an updated parameters control procedure is already pending
LL_STATUS_ERROR_DIFFERENT_TRANS_COLLISION (0x2A): master's update control procedure collides with slaves update control procedure

Strangely, I do not see any of these values map to the error codes you are seeing (0x69, 0xF0, 0x14, 0x2F). In fact most of these are not defined as any error codes in the stack at all. Are you sure you're reporting these correctly?

0 DU over 9 years ago in reply to Tim C

Prodigy 120 points

Hi Tim,

Thanks you very much for you answer.

I am using the hex files of the central and the peripheral (without modifying them at all). After 6 sec since the establishment of the connection, the parameters of the connection are updated and on the screen of the master I can see those values. I can confirm that I have seen all of them, in decimal form on the screen. I can upload a picture tomorrow morning, but I can tell you that I tried today one more time and I got 105 (0x69), as most of the time.

I am trying with these hex files exactly because I wanted to be sure that It was not my code that was producing these results.

Thanks again,

Daniel

0 DU over 9 years ago in reply to DU

Prodigy 120 points

Hi Tim,

I have just tried again and got the same results.

I hope to hear from you soon,

Daniel

0 Tim C over 9 years ago in reply to DU

TI__Mastermind 34660 points

So if I wanted to replicate this, I would:
1. Load CC2640_SmartRF-7ID_SimpleBLECentral.hex and CC2640_SmartRF-7ID_SimpleBLEPeripheral.hex included with the 2.1 installer
2. Connect and run for 6 minutes

Is that it?

0 DU over 9 years ago in reply to Tim C

Prodigy 120 points

Hi Tim,

Yes, after loading those hex files and creating the connection, after 6 seconds you'll see on the central device screen the Param update text.

0 Tim C over 9 years ago in reply to DU

TI__Mastermind 34660 points

That seems impossible but I'll try it out.

0 DU over 9 years ago in reply to Tim C

Prodigy 120 points

I have been seeing those different values since the very first time (105 being the one about 85% of the times). I have seen "0" only once, as a matter of fact. I tried to go backwards in the code and neither did I find them at all.
Thanks for your help!
BR,
Daniel

0 Tim C over 9 years ago in reply to DU

TI__Mastermind 34660 points

Ok I see what is happening...

When the link update event (gapLinkUpdateEvent_t) is sent by the stack, the status of the event is actually being set to the status of the osal event (yellow) instead of the event status (green):

typedef struct
{
  osal_event_hdr_t hdr;     //!< GAP_MSG_EVENT and status
  uint8 opcode;             //!< GAP_LINK_PARAM_UPDATE_EVENT
  uint8 status;             //!< bStatus_t
  uint16 connectionHandle;  //!< Connection handle of the update
  uint16 connInterval;      //!< Requested connection interval
  uint16 connLatency;       //!< Requested connection latency
  uint16 connTimeout;       //!< Requested connection timeout
} gapLinkUpdateEvent_t;

typedef struct
{
uint8 event;
uint8 status;
} osal_event_hdr_t;

The application, however, is checking the event status which is not set so it is reading whatever the last value was in RAM. I've filed this as a bug and it will be fixed.

In the meantime, you can do the following in the application:

    case GAP_LINK_PARAM_UPDATE_EVENT:
      {
        LCD_WRITE_STRING_VALUE("Param Update:", pEvent->linkUpdate.hdr.status,
                                10, LCD_PAGE2);
      }

Bluetooth®︎

Bluetooth forum

Connection Interval Update