[参考译文] CC2340R5：BLE 中央器件重新连接到外设时出现问题

您好 Alex、

感谢您的联系。

您是否有一个嗅探器来监控无线通信发生的情况并检查 BLE 通信的状态？ 您如何在测试中执行断开连接？ 您是否在之后重置设备？ 是否重新启用广播？

BR、

David

您好、David、

1. 我一直在使用 Wireshark 来监控信标。
   1. 通过本文、我可以看到、当移动设备端的连接尝试失败时、CC2340R53 仍在广播。
2. 断开连接由中央器件发起、终止事件出于调试目的记录在我们的 CC2340R53 器件中、因此、例如我们可以在成功连接测试期间看到这一点：
   1772391889，警告，诊断，连接状态：已建立 — 连接至 0x4CADFCB4B9D5 连接 Handle = 0、app_connection.c
   1772391889、警告、诊断、连接编号：1、app_connection.c
   1772391894、警告、诊断、连接终止！ （原因：19）、app_connection.c
3. 在不成功的测试期间、我们不会收到链路建立事件、并会继续广播。
4. CC2340R53 在发生故障后未重新启动、但在手机无法重新连接的情况下、我使用了另一个器件触发 CC2340R53 的重新启动、随后连接尝试继续失败。 此外、在故障期间、我可以在另一个移动设备上使用 nrf 连接进行连接、而另一个设备仍出现故障、因此它不处于不可连接状态。

 链路层中是否生成了任何事件可用于查看 CC2340R53 是否甚至看到连接请求或响应？ 是否有任何事件被触发、我可以附加回调以记录事件发生了？

您好！

您能否发布失败连接的 Wireshark 日志？ 这将使我们能够缩小断开连接的原因。

如果即使在 CC2340R53 外围设备重新启动后仍然遇到重新连接问题、则问题可能来自绑定。 您是否可以尝试清除故障后的绑定信息并查看设备是否仍然失败？

此致、
Lea

在 我们到目前为止的测试之后、由于这个问题可能有点复杂、难以重现、因此我们似乎没有任何优秀的 Wireshark 捕获示例来清楚地说明这个问题。 此外、我们发现此问题可能与我们在现场看到的故障不同。 我们仍在努力区分它们是否属于同一问题、或者由于我们运行的某些测试配置而产生的单独问题。 此外,我们不确定这些故障模式的发生是否出于完全相同的原因,或者不是在 Android 和 iOS 上发生,因为我们在测试时观察到了它们行为的细微差异。

我们的外围设备不应该与手机绑定、因此希望这不会导致问题。 它们只是应该建立一个链接和 r/w 一些 GATT 特性。

我们希望确定 CC2340R53 是否实际收到 CONNECT_IND。 您是否知道我们可以附加回调以在外设端记录此信息的最早事件？ 我们正在尝试在链路层中找到可以记录的最早位置。 否则、如果有任何其他方法来检测这些类型的早期链路层事件、我们非常希望提供建议。

谢谢您、

Alex Trujillo

您好！

由于您不确定许多参数、并且由于问题不容易重现、因此很难进行诊断。 如果您根本不使用绑定、但仍在使用配对、则问题肯定不是绑定信息？  

如果没有链路层的源代码、就无法启用链路层日志记录。 我最好的办法是利用 BleAppUtil 事件处理程序、在应用层进行 BLE 日志记录。 您可以在 C：\ti\simplelink_lowpower_f3_SDK_9_14_02_16\source\ti\ble\app_util\framework\bleapputil_api.h 文件中找到可以侦听的所有可能事件。 最相关的值是来自 BLEAppUtil_GAPConnEventMaskFlags_e 枚举的值、或者如果您需要更薄的控件、则是 BLEApp Util_Hci EventMaskFlags_e 枚举。

如果将来您有更多信息、或者能够生成可重现性最小的示例、我很乐意提供帮助。

此致、
Lea