CC2640R2F: BLE Disconnect after 'Connection Parameters Request' rejection on MacOS 11.4

Hi Scott,

Thank you for reaching out to us and for providing such a detailed write-up. I have a few questions that may help us get to the bottom of this in a more efficient manner. What SDK is being used on the device? What is the reproducibility of this behavior? Do you see other BLE devices having this behavior with MacOS 11.4? Thank you for providing the sniffer log this is very helpful in giving us additional context.

Best Regards,

Jan

Hi Jan.

Thank you for the quick response.

I am using the 5.10.0.2 SDK and it is 100% reproduceable.  This is our first product that uses the R2 processor.  All of our previous products use the CC2640F128 with BLE SDK 2.2.2 and do not exhibit the problem.

As I was preparing to send you my initialization code, I ran across the following:

GAPRole_SetParameter(GAPROLE_PARAM_UPDATE_ENABLE, sizeof(uint8_t), &enableUpdateRequest);

If I set GAPROLE_PARAM_UPDATE_ENABLE to 'false', the problem goes away.

So my follow-up question is: Will setting GAPROLE_PARAM_UPDATE_ENABLE to 'false' have any negative impact on performance (e.g. will connection intervals be longer, will more connections be potentially rejected, etc...)?

Thank you

Scott

Hi Scott,

I am glad to hear you were able to find a workaround for this. Setting that to false makes it such that the peripheral does not request a connection parameter update upon a connection being formed. This means you can still try to request a connection parameter update later on in the connection. I suggest keeping this disabled and attempting to change the connection parameters a few seconds after a connection has been successfully established to verify if the same behavior is seen. Can you perform this test and let us know what the resulting behavior is?

Best Regards,

Jan

Hi Jan.

Per your suggestion, I kept the auto update disabled and instead manually made the update request after the connection had settled via:

GAPRole_SendUpdateParam(6, 24, 0, 1000, GAPROLE_NO_ACTION);

Unfortunately, the results are the same.  In the sniffer log, you can see that I make the request at 00:50.518, and the connection is lost somewhere around 01:30.300.  I can't tell which side dropped the connection.

Control Node Unexpected Disconnect from Mac 2.zip

Thank you

Scott

Hi Scott,

While doing some research for this, I came across this page that details what the connection parameter requirements are from the MacOS side: https://developer.apple.com/library/archive/qa/qa1931/_index.html

Can you verify if you are setting the parameters such that they are within the range they expect them to be?

Best Regards,

Jan

Hi Jan

I tried bumping the minimum connection interval to 15ms and dropping the supervisory timeout to 5s so that all parameters would comply with the Apple recommendations, but the update was still rejected.

Good find though.

Thank you

Scott

Hi Scott,

Thanks for the quick test! I attempted to look through the second log you gave, but I saw many blank entries and could not find the param request packet. Can you resend it and attach screenshots of where its located in the log?

Best Regards,

Jan

Hi Jan.

Here is a screenshot of the offending packet.  Hopefully you can see it since this forum shrinks the image down quite a bit.

The packet in question is at frame #57737 in the 'LE LL' tab view. 

I downloaded and tested the .zip file I previously sent you and it had the correct information in it, so I think you have the correct files.  I'll re-zip and re-upload them here just in case.

Control Node Unexpected Disconnect from Mac 2 (2).zip

Thank you

Scott

Hi Scott,

Thank you. Strangely, I am able it properly today. Last time I tried, it was showing up as blank. I am guessing restarting my PC must have fixed the problem. Thank you for the prompt response! I have been doing some research on this behavior and found a similar thread: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/720425/cc2640r2f-connection-parameters-update-issue

Can you verify if this issue is present when using the L2CAP connection parameter request instead?

Best Regards,

Jan