CC2640R2F: GAP_UpdateLinkParamReqReply issue

Hi Vsevolod,

It's always the Central side (i.e. Android device) that mandates the connection interval. The peripheral device can request other connection parameters, but it's not certain that it will be accepted.

Hi Joakim,

Yes, I understand that the Central side decides.

But Peripheral should have chance to provide their preferred parameters. Please refer to spec Vol 6, Part B 5.1.7.2: Responding to LL_CONNECTION_PARAM_REQ and LL_CONNECTION_PARAM_RSP PDUs

If the received LL_CONNECTION_PARAM_REQ PDU contains parameters
that are not acceptable to the Link Layer, then the Link Layer of the device shall
respond to the LL_CONNECTION_PARAM_REQ PDU with one of the
following:
• An LL_CONNECTION_PARAM_RSP PDU (if the Link Layer is the slave of
the connection) or an LL_CONNECTION_UPDATE_IND PDU (if the Link
Layer is the master of the connection) containing alternative parameters.
• An LL_REJECT_EXT_IND PDU with the ErrorCode set to Unsupported LL
Parameter Value (0x20).

So if parameters requested by Android are not acceptable, the device should response with  LL_CONNECTION_PARAM_RSP PDU with alternative parameters. Yes, I know that Central can ignore them, but also may accept.

Why our stack always responses with requested parameters only and refuse the provided alternative?

How to make it response with our parameters?

Hi,

We do not have such functionality in our BLE stack (i.e. auto negotiate connection interval). The stack can only request what the application is requesting, which means that the application must potentially request again if the connection parameters weren't updated.

Joakim,

I'm not asking about any auto negotiation.

I'm asking how to make our stack put alternative parameters into LL_CONNECTION_PARAM_RSP as stated in BLE spec?

Hi Seva,

Sorry for the late answer.

Did you define USE_LL_CONN_PARAM_UPDATE in your project?

Hi Marie,

There was no USE_LL_CONN_PARAM_UPDATE in the project. But nothing had changed when I define the USE_LL_CONN_PARAM_UPDATE in project's predefines symbols and rebuild the project. No changes.

Marie, are you wondered in the Connection Parameters Update Procedure support?

Slave device support it as shown in Feature response:

Hi Seva,

I just tested with simple peripheral and I am not able to reproduce what you're seeing:

1) Import simple peripheral from 3.20 SDK

2) Define USE_LL_CONN_PARAM_UPDATE in app project predefined symbols

3) Set GAPROLE_LINK_PARAM_UPDATE_WAIT_APP_PARAMS

4) Use Btool + Host test as the master device. Scan and connect to simple peripheral

5) Send a GAP_UpdateLinkParamReq() from BTool

6) Simple peripheral answers with Connection Parameter Update Response with its own parameters (DEFAULT_DESIRED_MAX_CONN_INTERVAL etc). 

Did they make any code changes that could cause this?

Hi Marie,

Please try to repeat this with simple_peripheral_cc2640r2lp_oad_onchip_app

I checked with reading simpleProfile char5 by android phone. The char5 requires authentication, and android automatically start con param update procedure. As you can see - the device response with remote parameters instead of local ones.

Hi Seva,

I just tested with simple peripheral oad onchip from the SimpleLink CC2640R2 SDK 3.20. I am still not able to reproduce. Simple Peripheral sends a connection parameter response with its own parameters.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/538/workspace_5F00_ble.7z

Hi Marie,

Please find my archived workspace in the attachment.

I see this behavior:

Hi Seva,

I am totally confused. As far as I can tell we are testing the same thing (default simple peripheral oad on-chip example from the 3.20 SDK with some modifications in simple_peripheral_oad_onchip.c), but we are getting different results.

Are you using a custom board? Did you make any changes in the BLE-Stack files? 

Hello friend, have you solved this problem? I have the same problem as you.

Hi Jessie,

Not yet.

There is some workaround:

Peripherial device send their own parameters update after some timeout(see DEFAULT_CONN_PAUSE_PERIPHERAL). If suitable parameters was achieved – update GAPROLE_PARAM_UPDATE_ENABLE to GAPROLE_LINK_PARAM_UPDATE_REJECT_REQUEST to prevent all other updates.

If master will perform force update of connection parameters – peripheral will just drop the connection.

Its looks like dirty hack but it works. There is some code snippet:

static void SimplePeripheral_processConnUpdate(gapParamUpdateEvent_t *pData) {
//    // If we achieved desired connInterval - reject all further Param Update Requests
    if(pData->connInterval > DEFAULT_DESIRED_MIN_CONN_INTERVAL) {
        uint8_t enableUpdateRequest = GAPROLE_LINK_PARAM_UPDATE_REJECT_REQUEST;
        GAPRole_SetParameter(GAPROLE_PARAM_UPDATE_ENABLE, sizeof(uint8_t),
                             &enableUpdateRequest);
    } else {
        GAPRole_TerminateConnection(HCI_DISCONNECT_UNACCEPTABLE_CONN_INTERVAL);
    }
}

Thank you for your reply !

I did the same. Otherwise my two other Bluetooth devices will be disconnected.