CC2640R2F: LL response timeout due to wrong sequencing

Hello Patrik,

Thank you for reaching out.

May I kindly ask you to specify the full part number of the device being used (CC2640R2F-Q1, CC2640R2F or CC2640R2L). This way we can ensure your question is routed to the proprr team.

In addition, may I kindly ask you to estimate the reproducibility rate? Do you manage to reproduce this 100% of the time when connecting to a Samsung A12? Also, do you mange to reproduce using other phones and different OS (especially iOS)?

Best regards,

Hello Clément,

It is CC2640R2F.

Issue reproducibility rate:

• 100%  with Samsung A12 (One UI 4.1, Android 12)
  • capture provided in 1st post
  • GAP link terminated event with code 0x22
  • time conn terminations ~40 s
• 100% with Samsung S10E (Lineage OS 20, Android 13)
  • ble_android_s10e_conn-param_possibly_failed_conn_drops.zip
  • GAP link terminated event with code 0x08
  • It takes a bit more time before connection is terminated (~49 s)
• 0% with iPhone 12 Pro (iOS 15.4.1)
  • iphone_def_conn_params_ok_2.zip

Hi Patrik,

Thank you for these details.

For information, I cannot open the sniffer logs you have provided as they have been collected with a tool (competitor sniffer) I don't have access to.
But, at first sight it seems the phone is sending a LL control procedure before the completion of the previous one.
Could you please check if the same occurs with the Samsung S10E? Also, could you confirm this does NOT happen for the iPhone 12 Pro ?

Best regards,

Hello Clément,

Even though capture of BLE  and decoding was done by competitor sniffer tool, output is in independent open pcapng format which can by be opened by open source software Wireshark. No need for any competitor tools for viewing these logs. If possible, please try to get access to it.

But, at first sight it seems the phone is sending a LL control procedure before the completion of the previous one.

Can you specify line numbers leading you to this assumption (column "No.")? Most of the code is from Simple Central example - CC2640R2F is master here and 90% of LL requests is started by master.

The only requests I trigger in code is LL_CONNECTION_PARAM_REQ and MTU change.

Until I started sending LL_CONNECTION_PARAM_REQ, everything worked fine.

iPhone 12 Pro:

mostly fine, new connection timing is used since line 91

Samsung S10e:

Hi Patrik,

Thank you for the additional information provided.

For information, the challenge is not necessarily to open the files with Wireshark, but rather to access the file "dissector". Anyway, the screenshots you have provided should be helpful.

Clément said:

But, at first sight it seems the phone is sending a LL control procedure before the completion of the previous one.

This comment is actually incorrect. I should have written the "central" (CC2640R2F) device is sending a LL control procedure before the completion of the previous one. Apologize for this confusion.
I am not sure this is actually a serious lead as the same can be observed on the iPhone log (lines 60 and 61 with LL_VERSION_IND are sent in the middle of the LL_LENGTH procedure).

Looking in the Samsung S10e log, I see the master/CC2640R2 send the packet LL_REJECT_EXT_IND. It would be interesting to gather more information about this packet. For example, which oppCode is being rejected and which ErrorCode is being reported.

For sanity, please also check if phone supports the Extended Reject Indication Link Layer feature. This check can be done looking at the LL_FEATURE_RSP sent by the phone.

Best regards,

Interesting, my vanilla installation of Wireshark 4.2.2 on different machine has this competitor protocol dissector available. It's unfortunate you can't use it.

Ti Smart packet sniffer 2 has very limited board support, does not work on GNU/linux, does not work with up to date Wireshark (4.2.2) and Launchpad micro USB connectors with only 2 THT anchors are very fragile. That's the reason why I use alternative BLE sniffing tool.

Anyway...

Clément said:

I am not sure this is actually a serious lead as the same can be observed on the iPhone log (lines 60 and 61 with LL_VERSION_IND are sent in the middle of the LL_LENGTH procedure).

I think these LL_VERSION_IND does not matter as they are not requests and do not require any response, thus do not collide with other LL transaction.

iPhone reported these BLE features (length extension supported):

.... ...1 = LE Encryption: True
.... ..1. = Connection Parameters Request Procedure: True
.... .1.. = Extended Reject Indication: True
.... 1... = Slave Initiated Features Exchange: True
...1 .... = LE Ping: True
..1. .... = LE Data Packet Length Extension: True
.1.. .... = LL Privacy: True
1... .... = Extended Scanner Filter Policies: True
.... ...1 = LE 2M PHY: True
.... ..0. = Stable Modulation Index - Transmitter: False
.... .0.. = Stable Modulation Index - Receiver: False
.... 1... = LE Coded PHY: True
...1 .... = LE Extended Advertising: True
..1. .... = LE Periodic Advertising: True
.1.. .... = Channel Selection Algorithm #2: True
0... .... = LE Power Class 1: False
.... ...1 = Minimum Number of Used Channels Procedure: True
.... ..0. = Connection CTE Request: False
.... .0.. = Connection CTE Response: False
.... 0... = Connectionless CTE Transmitter: False
...0 .... = Connectionless CTE Receiver: False
..0. .... = Antenna Switching During CTE Transmission (AoD): False
.0.. .... = Antenna Switching During CTE Reception (AoA): False
0... .... = Receiving Constant Tone Extensions: False
.... ...0 = Periodic Advertising Sync Transfer - Sender: False
.... ..0. = Periodic Advertising Sync Transfer - Receiver: False
.... .0.. = Sleep Clock Accuracy Updates: False
.... 0... = Remote Public Key Validation: False
...0 .... = Connected Isochronous Stream - Central: False
..0. .... = Connected Isochronous Stream - Peripheral: False
.0.. .... = Isochronous Broadcaster: False
0... .... = Synchronized Receiver: False
.... ...0 = Connected Isochronous Stream (Host Support): False
.... ..0. = LE Power Control Request: False
.... .0.. = LE Power Control Request: False
.... 0... = LE Path Loss Monitoring: False
...0 .... = Periodic Advertising ADI support: False
..0. .... = Connection Subrating: False
.0.. .... = Connection Subrating (Host Support): False
0... .... = Channel Classification: False
.... ...0 = Advertising Coding Selection: False
.... ..0. = Advertising Coding Selection (Host Support): False
.... .0.. = Periodic Advertising with Responses - Advertiser: False
.... 0... = Periodic Advertising with Responses - Scanner: False
0000 .... = Reserved bits: 0
Reserved: 0000f9

CC2640R2F rejects PHY change (@69)

• Reject Opcode: LL_PHY_REQ (0x16)
• Error Code: Different Transaction Collision (0x2a)

S10e reported these BLE features

.... ...1 = LE Encryption: True
.... ..1. = Connection Parameters Request Procedure: True
.... .1.. = Extended Reject Indication: True
.... 1... = Slave Initiated Features Exchange: True
...0 .... = LE Ping: False
..1. .... = LE Data Packet Length Extension: True
.1.. .... = LL Privacy: True
1... .... = Extended Scanner Filter Policies: True
.... ...1 = LE 2M PHY: True
.... ..0. = Stable Modulation Index - Transmitter: False
.... .0.. = Stable Modulation Index - Receiver: False
.... 1... = LE Coded PHY: True
...1 .... = LE Extended Advertising: True
..1. .... = LE Periodic Advertising: True
.1.. .... = Channel Selection Algorithm #2: True
0... .... = LE Power Class 1: False
.... ...1 = Minimum Number of Used Channels Procedure: True
.... ..0. = Connection CTE Request: False
.... .0.. = Connection CTE Response: False
.... 0... = Connectionless CTE Transmitter: False
...0 .... = Connectionless CTE Receiver: False
..0. .... = Antenna Switching During CTE Transmission (AoD): False
.0.. .... = Antenna Switching During CTE Reception (AoA): False
0... .... = Receiving Constant Tone Extensions: False
.... ...0 = Periodic Advertising Sync Transfer - Sender: False
.... ..0. = Periodic Advertising Sync Transfer - Receiver: False
.... .0.. = Sleep Clock Accuracy Updates: False
.... 0... = Remote Public Key Validation: False
...0 .... = Connected Isochronous Stream - Central: False
..0. .... = Connected Isochronous Stream - Peripheral: False
.0.. .... = Isochronous Broadcaster: False
0... .... = Synchronized Receiver: False
.... ...0 = Connected Isochronous Stream (Host Support): False
.... ..0. = LE Power Control Request: False
.... .0.. = LE Power Control Request: False
.... 0... = LE Path Loss Monitoring: False
...0 .... = Periodic Advertising ADI support: False
..0. .... = Connection Subrating: False
.0.. .... = Connection Subrating (Host Support): False
0... .... = Channel Classification: False
.... ...0 = Advertising Coding Selection: False
.... ..0. = Advertising Coding Selection (Host Support): False
.... .0.. = Periodic Advertising with Responses - Advertiser: False
.... 0... = Periodic Advertising with Responses - Scanner: False
0000 .... = Reserved bits: 0
Reserved: 00003b

S10e connection request related packets details:

LL_CONNECTION_PARAM_REQ

• Interval Min: 12
• Interval Max: 40
• Latency: 0
• Timeout: 200

LL_CONNECTION_PARAM_RSP

• Interval Min: 36
• Interval Max: 36
• Latency: 0
• Timeout: 200

LL_REJECT_EXT_IND

• Reject Opcode: LL_CONNECTION_PARAM_REQ (0x0f)
• Error Code: Invalid LMP/LL Parameters (0x1e)

I am not sure what CC2640R2F BLE stack does not like about those parameters in response.

Hi,

I have reviewed the content of the LL_CONNECTION_PARAM_RSP. The intervals specified, the latency and the timeout seem to be correct.
For sanity, could you please check the value of the "reference connection event count" and of the offsets. To do this, you should ensure all these events are in the future (i.e. reference connection event count + offset is larger than the current connection event).

In addition to this, could you please review the content of the LL_CONNECTION_PARAM_RSP sent by the iPhone? I would like to see if we can spot something that could put on a lead.
Similarly, could you try to change the connection parameters requested to the Android phone? It would then be interesting to see if it has an impact.
Last but not least, could you try to delay the connection parameters request?

Best regards,

This topic is still opened, please don't close this discussion yet. I just have to focus on different topic at this moment. I will come back in upcoming weeks.