[参考译文] CC2640R2F：定序错误导致的 ll 响应超时

尊敬的 Patrik：

感谢您与我们联系。

请您指定正在使用的器件的完整器件型号(CC2640R2F-Q1、CC2640R2F 或 CC2640R2L)。 通过这种方式、我们可以确保将您的问题发送给 proprr 团队。

此外,我还想请您估计再现率? 在连接到三星 A12时、您是否设法100%复制此时间？ 此外,你是否会通过使用其他电话和不同的操作系统(尤其是 iOS )来复制?

此致、

您好，Clement，

它是 CC2640R2F。

问题重现性率：

• 100% 使用 Samsung A12 (One UI 4.1、Android 12)
  • 在第1个帖子中提供捕获
  • 使用代码0x22的 GAP 链接终止事件
  • 时长终端~40s
• 100%使用三星 S10E (沿袭 OS 20、Android 13)
  • e2e.ti.com/.../ble_5F00_android_5F00_s10e_5F00_conn_2D00_param_5F00_possibly_5F00_failed_5F00_conn_5F00_drops.zip
  • 使用代码0x08的 GAP 链接终止事件
  • 连接终止之前需要更长时间(~49s)
• 0%使用 iPhone 12 Pro (iOS 15.4.1)
  • e2e.ti.com/.../iphone_5F00_def_5F00_conn_5F00_params_5F00_ok_5F00_2.zip

尊敬的 Patrik：

感谢您提供这些详细信息。

我无法打开您提供的监听器日志、因为它们是使用我无法访问的工具(竞争对手监听器)收集的。
但是、乍一看、手机似乎在前一个任务完成之前正在发送 LL 控制程序。
您能否检查三星 S10E 是否同样发生这种情况？ 此外,你能确认这不会发生在 iPhone 12 Pro 吗?

此致、

您好，Clement，

尽管 BLE 和解码捕获是由竞争对手的监听工具完成的、但输出是独立的开放捕获格式、可以通过开放源码软件 Wireshark 打开该格式。 无需任何竞争对手的工具即可查看这些日志。 如有可能、请尝试访问。

但是、乍一看、手机似乎在前一个任务完成之前正在发送 LL 控制程序。

您是否可以指定能够引导您作出此假设的行号(列"否")？ 大部分代码来自 Simple Central 示例- CC2640R2F 在这里是主器件、90%的 LL 请求由主器件启动。

我在代码中触发的唯一请求是LL_CONNECTION_PARAM_REQ和 MTU 更改。

直到我开始发送LL_CONNECTION_PARAM_REQ,一切工作正常。

iPhone 12 Pro：

大多数情况下很好、使用新的连接时序、因为线路91

三星 S10e：

尊敬的 Patrik：

感谢您提供的其他信息。

相关信息、挑战不一定要使用 Wireshark 打开文件、而是访问文件"dissector"。 无论如何、您提供的屏幕截图应该会有所帮助。

Unknown 说：

但是，乍看之下，电话似乎在完成前一个程序之前正在发送 LL 控制程序。 [/报价]

此注释实际上不正确。 我应该已经写入"中央"(CC2640R2F)器件正在发送 LL 控制程序、然后再完成前一个程序。 为这种困惑道歉。
我不确定这实际上是一个严重的线索,因为可以在 iPhone 日志上观察到相同的(第60行和第61行 LL_VERSION_IND 在 LL_LENGTH 程序的中间发送)。

在 Samsung S10e 日志中、我看到主器件/CC2640R2发送数据包 LL_RESET_EXT_IND。 收集有关此数据包的更多信息会很有趣。 例如、哪个 oppCode 被拒绝、哪些 ErrorCode 被报告。

为了健全性、还请检查电话是否支持扩展拒绝指示链路层功能。 可通过查看手机发送的 LL_FEATURE_RSP 来完成此检查。

此致、

有趣的是,我在不同机器上的 Wireshark 4.2.2的香草安装有这个竞争对手的协议分解器可用。 不幸的是、您无法使用它。

TI 智能数据包监听器2的电路板支持非常有限、不能在 GNU/Linux 上运行、不能与最新的 Wireshark (4.2.2)配合使用、以及仅具有2个 Th 锚点的 Launchpad 微型 USB 连接器非常脆弱。 这就是我使用替代 BLE 监听工具的原因。

反正...

Unknown 说：

我不确定这实际上是一个严重的线索,因为可以在 iPhone 日志上观察到相同的线索(第60行和第61行带有 LL_VERSION_IND 在 LL_LENGTH 过程的中间发送)。[/引号]

我认为这些 LL_VERSION_IND 无关紧要、因为它们不是请求、不需要任何响应、因此不与其他 LL 事务相冲突。

iPhone 报告了以下 BLE 特性(支持长度扩展)：

.... ...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 抑制 PHY 更改(@69)

• 拒绝操作码：LL_PHY_REQ (0x16)
• 错误代码：不同的事务冲突(0x2a)

S10E 报告了这些 BLE 特性

.... ...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 连接请求相关数据包详细信息：

LL_CONNECTION_PARAM_REQ

• 最小间隔：12
• 最大间隔：40
• 延迟：0
• 超时：200

LL_CONNECTION_PARAM_RSP

• 最小间隔时间：36
• 最大间隔时间：36
• 延迟：0
• 超时：200

LL_Reject_EXT_IND

• 拒绝操作码：LL_CONNECTION_PARAM_REQ (0x0F)
• 错误代码：无效的 LMP/LL 参数(0x1E)

我不确定 CC2640R2F BLE 堆栈对这些参数的不喜欢程度。

您好！

我已经回顾了 LL_CONNECTION_PARAM_RSP 的内容。 指定的时间间隔、延迟和超时似乎是正确的。
为了确保完整性、您可以检查"基准连接事件计数"的值和偏移值。 为此、您应确保所有这些事件都是未来的(即参考连接事件计数+偏移大于当前连接事件)。

除此之外、您能否查看 iPhone 发送的 LL_CONNECTION_PARAM_RSP 的内容？ 我想看看我们是否能发现可以在一个线索的东西。
同样、您可以尝试更改请求到 Android 手机的连接参数吗？ 那么、看看它是否产生影响很有趣。
最后但同样重要的是、您能否尝试延迟连接参数请求？

此致、

此主题仍处于打开状态、请不要关闭此讨论。 现在我只需要关注不同的话题。 我将在未来几周内回来。