CC2642R: Need example or a way to respond back to master with LL_REJECT_IND for received LL_CONNECTION_PARAM_REQ from master

Hi Ammar,

My question was to understand how the BLE stack notifies the application when the connection parameter update request sent by the peripheral but has been resulted into collision (Vol 6: Part B: 5 Link Layer Protocol: 5.3 Procedure collisions). How does the application will come to know from the BLE stack when the update request has been rejected due to collision?

Mehul

Hey Mehul,

Thanks for the clarification. The status should be returned in the GAP_LINK_PARAM_UPDATE_EVENT callback for the procedure. I believe the status code's are listed in ll.h, If you have a test case that can reproduce it, try adding a check at the application for LL_STATUS_ERROR_TRANSACTION_COLLISION. 

A similar check could be added for a failed PHY update as well.

FYI - Some context provided in a related post: e2e.ti.com/.../connection-interval-update

HI Ammar,

We are not getting GAP_LINK_PARAM_UPDATE_EVENT notification if the collision is detected. We are also not seeing REJECT response form the client is such case on Ellisys. Is it fair to expect REJECT_IND from client in such case as the specification said the same?

Mehul

Hey Mehul,

If the Ellisys did not capture a collision, I would revisit the flow of events that is observed to ensure there was indeed a control procedure collision as the specification outlines. Assuming there is a control procedure collision, the Ellisys should capture such a response. This is the first point we should verify before checking the status codes given to the application.

Hi Ammar,

Allow me couple of days to report the Ellisys capture. I have few more points as well to talk about.

Mehul

Hi Ammar,

I am able to get Ellisys capture. Note that the behavior is observed between the Windows 10 BLE client (In built BLE driver) and Simple Peripheral firmware.

Somehow, the Ellisys capture itself is not attached in this post even I tried multiple times. So, I am putting snippets only.

- When the client did accepted the L2CAP Parameter Update request from the peripheral but no Connection Update Indication is received:

- The same Windows 10 BLE client few times sends the connection update indication which should have done in above case as well. So, is the BLE client is non conformant when it does not send Connection Update Indication after accepting the request?

Hi Mehul,

Ammar has asked me to help while he is unavailable. Thank you for your comprehension.

Looking at the capture provided, I am not sure I can spot the issue.

• The L2CAP parameter update (BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part C, §9.3.9) looks correct to me. The L2CAP_CONNECTION_PARAMETER_UPDATE_RSP command follows the L2CAP_CONNECTION_PARAMETER_UPDATE_REQ
• The connection parameter update triggered by the LL Control PDU (BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 6, Part B, §5.1.1) looks also correct to me.

In that case, I assume the devices are first using the L2CAP parameter update as the hosts are not aware if the LL supports parameters update procedure - the LL feature exchange is sent right before the L2CAP parameter update. This means the host was probably not aware this at the time the packet was enqueued.

Please let me know if I have missed something.

Best regards,

Clement,

Can you elaborate "In that case, I assume the devices are first using the L2CAP parameter update as the hosts are not aware if the LL supports parameters update procedure - the LL feature exchange is sent right before the L2CAP parameter update. This means the host was probably not aware this at the time the packet was enqueued."? You are correct in specifying that the peripheral has used L2CAP parameter update.

The issue we are facing is with the 1st image that was inserted where the L2CAP parameter update is started and was accepted by the master. But it was not followed by LLCP Connection Update Indication like the 2nd image has it (LLCP connection update indication).

Hi Clement,

A gentle reminder on above request.

Hi Clement,

Thanks for the reply.

Let me clarify few points. It is a peripheral which is initiating L2CAP Connection Parameter Update procedure (using L2CAP_ConnParamUpdateReq()) always not the master. 2nd, this request is considered as completed only if LLCP Connection Update Indication is received from master. As per the BLE spec, Vol 6, Part D, Section 6.12, figures 6.15 and 6.16, the master must the the indication/reject packet in the response.

If the peripheral retires again sending L2CAP connection parameter update using L2CAP_ConnParamUpdateReq() API, the TI BLE stack itself returns 17d return code i.e. 0x11 while calling this API in the application firmware. So, the earlier L2CAP request must be completed form the master either by sending the indication or rejecting it. As per attached image earlier, the master does send the indication sometimes but sometimes not due to which the L2CAP connection parameter udpate procedure is not completed.

Hey Mehul,

Mehul Dalal said:

As per the BLE spec, Vol 6, Part D, Section 6.12, figures 6.15 and 6.16, the master must the the indication/reject packet in the response.

These figures actually apply to an LL Connection parameter update, not necessarily an L2CAP Connection parameter update, which you can ready more about in Vol 3, Part A, 4.20 L2CAP_CONNECTION_PARAMETER_UPDATE_REQ. That being said, since the master has accepted it, I would expect an indication to update it.

Can you please retry to upload the sniffer log? Just to make sure, you can upload it by going to Insert>Image/VIdeo/File. I would like to see the full detail of the sniffer log just to ensure there is an issue here.

Additionally, are you are able to reproduce this behavior on a minimally modified example?

Hi Ammar,

I have attached the two captures here as you have suggested. However, the .btt extension still did not work so I changed the extension. Kinldy rename these files with .btt extension to get them opened in the Ellisys.

I have not tried to use the Simple Peripheral application directly as such but do you need it? I believe it is just about sending L2CAP request immediately after the connection is established and see if it always works with Windows based BLE client.

L2CAP accepted but no LL Indication.txtL2CAP accepted and followed by LL indication.txt

Hey Mehul,

Do you see this occur when the device requests a change in connection parameters (try changing it from 45 ms max to something smaller, forcing an update)? As I see it and as Clement alluded to, perhaps the request is accepted, but since it effectively does not result in any change, maybe an LL update indication is not needed in that instance.

I will take a look at the logs and provide further comments.

Hi Ammar,

With another capture I had attached, the master does sent the Indication packet even though the parameters were already set. So, sometimes master is sending the indication and sometime not. That is what the issue is.

Also, I tried with high interval and the behavior is same as above with not consistent indication sent by the master.

Hi Ammar,

Any update from your end?

Mehul

Hey Mehul,

I apologize for the delay here. I've since tried to reproduce this issue, but am unable to. My application defaults to using LLCP connection parameter updates (as opposed to L2CAP).

Have you made any changes to the application that would force the use of L2CAP updates in place of LLCP? I can force this situation to occur on my end, but rather than hack the example, I would rather understand the changes made to the application that would reproduce this. Any insight here would be helpful.

Hi Ammar,

We have used L2CAP_ConnParamUpdateReq() API to be called immediately after receiving Link Establish event from he BLE stack. Are you using similar API as well?

Also, note that this behavior is observed with Windows BLE client only not with BTool or Android devices.

Hey Mehul,

The default examples actually use the GAP_UpdateLinkParamReq API. This API will attempt an LL parameter update first, and if the feature is not supported by the controller, only then will the L2CAP procedure be attempted by the peripheral.

I would try this out to see if you see better performance. I'll try reproducing this with the API you mentioned.

Thanks Ammar. Keep me posted.

Hey Mehul,

I have not been able to test this out last week. Have you tested using GAP_UpdateLinkParamReq?

Hi Ammar,

No, I have not. I need to use the L2CAP only as that is what preferred by Android/Apple guidelines.

Requesting you to check the same at your end.

Hey Mehul,

I will have access to a sniffer tomorrow and will follow up then after some testing.

Hey Mehul,

I didn't see any issues connecting to my Windows machine. I used SDK 5.20 and am running Windows 10. 

I connect to SimplePeripheral using the native Windows settings.

EDIT: I've also tested with SDK 5.10. Is this issue intermittent? Can you try connecting to a different Windows 10 based PC?

To test, I've disabled the LL connection param update feature at the link layer, forcing the use of L2CAP. Our example by default sends a parameter update 6 seconds after connection establishment.

Hi Ammar,

What are the connection parameters when the Windows client initiates a connection with a peripheral? If the peripheral then tries to send the L2CAP connection update parameter request with having similar values, the windows accepts the request but does not send the IND. If the parameter requested by the peripheral are different then what has been set, the Windows client is seen sending the IND packet.

Hey Mehul,

I ran a test case to update the params to the same parameters as the initial connection and the issue did not occur.

It seems the issue is definitely on the Windows side. Let's try to delay sending the param update by a few extra ms (let's just try 500ms to start) since on my end I wait 6s. Perhaps Windows is busy processing another control procedure and never sends the indication because there is another process ongoing.

Hi Ammar,

The issue is observed with the windows BLE client only. 

Hi Ammar,

I understand that the TI side has no issue. But wanted to confirm if this was an indeed issue from Windows.