[参考译文] CC2640R2F：器件在 POCO 移动设备(Android 11)上的3个数据包后停止发送数据

您好！

感谢您的参与。

我建议检查是否可以使用从最新 SDK 获取的未修改工程复制相同的内容。 此外、最好能够确定引发问题的原因。 例如，不使用加密时是否可以重现？ 无论交换何种流量、该问题是否始终出现在3个数据包之后？ 等等

有关信息、我无法正确打开您提供的迹线。 (或者、该工具向我显示的数据包超过3个、其中有多个 MIC 问题和 L2CAP 重新组装错误、因此我想这不能按预期工作)。 您能否使用 TI 数据包监听器(https://www.ti.com/tool/PACKET-SNIFFER/)运行此测试或提供屏幕截图？

此致、

您好 Clement、  

1) 1)我无法使用我们硬件上未经修改的代码来检查它、因为我们的硬件基本上是经过修改的。 但我已经使用 Launchxl-cc2640f 作为器件在同一 POCO 移动设备上使用 nRFconnect 应用测试了 simplePeripheral 代码。 它每秒向手机发送数据、而不会失败。  

2) 2) 可以使用 Wireshark 应用程序查看我在上一条消息中附加的日志、如下链接所述。  

https://software-dl.ti.com/lprf/packet_sniffer_2/docs/user_guide/html/users_guide.html#required-hardware

3)关于我的应用、器件始终发送3个数据包并停止。 或者它不发送任何消息。 它不会向 POCO 电话发送超过3个数据包。 随附 Wireshark 应用程序的屏幕截图(btatt)、供您参考。  

4) 4)无论使用哪种连接间隔、它始终发送3个数据包或无数据包并停止。 有时固件挂起。  

5) 5)您能告诉我如何禁用加密吗？ 我不确定我们在哪里使用加密。  

e2e.ti.com/.../3021.logs.zip

最好

Lakshmi

您好！

[引用 userid="179339 " URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1177317/cc2640r2f-device-stops-sending-data-after-3-packets-on-poco-mobile-android-11/4434726 #4434726"]1)由于我们的硬件主要是修改的、因此我无法使用我们硬件上未修改的代码来检查它。 但我已经使用 Launchxl-cc2640f 作为器件在同一 POCO 移动设备上使用 nRFconnect 应用测试了 simplePeripheral 代码。 它每秒向手机发送数据、而不会失败。  [/报价]

有趣的是、该问题无法以这种方式重现。
当您说"每秒发送数据"时、您是否意味着此数据是通过通知发送的？ (我提出这一问题是因为这似乎是引发问题的原因)。

[引用 userid="179339" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1177317/cc2640r2f-device-stops-sending-data-after-3-packets-on-poco-mobile-android-11/4434726 #4434726"]

2) 2) 可以使用 Wireshark 应用程序查看我在上一条消息中附加的日志、如下链接所述。  

https://software-dl.ti.com/lprf/packet_sniffer_2/docs/user_guide/html/users_guide.html#required-hardware

[/报价]

实际上、这不是真的。 您已使用非 TI 工具收集了跟踪信息、因此需要一个非 TI Wireshark 插件、我出于许可原因无法访问该插件。

[引用 userid="179339" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1177317/cc2640r2f-device-stops-sending-data-after-3-packets-on-poco-mobile-android-11/4434726 #4434726"]3)关于我的应用程序，设备始终发送3个数据包并停止。 或者它不发送任何消息。 它不会向 POCO 电话发送超过3个数据包。 随附 Wireshark 应用程序的屏幕截图(btatt)、供您参考。  [/报价]

感谢您提供屏幕截图。
通过此连接发送的数据包超过3个。 但是、该问题似乎在外设发送处理0x000e 的3个通知后发生。 请注意、这3个通知是在同一个连接事件中发送的。

我建议尝试确认这一理论、因为这也可能是临时解决方法的一个线索。
为此、我建议尝试禁用通知并定期读取特征。

[引用 userid="179339 " URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1177317/cc2640r2f-device-stops-sending-data-after-3-packets-on-poco-mobile-android-11/4434726 #4434726"]4)无论我使用的连接间隔是多少，它始终发送3个数据包或不发送数据包并停止。 有时固件挂起。  [/报价]

有趣-固件在哪里挂起？ 您是否看到一些特定的错误代码？ 您能否检查内存问题是否导致问题？

[引用 userid="179339 " URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1177317/cc2640r2f-device-stops-sending-data-after-3-packets-on-poco-mobile-android-11/4434726 #4434726"]5)您是否可以告诉我如何禁用加密。 我不确定我们在哪里使用加密。  [/报价]

它实际上看起来不像您使用加密。 这种解释来自我以前用来审查所提供的迹线的工具。
因此、您可以忽略该注释。

此致、

您好！

1) 1)是、数据仅通过通知发送。 您能否详细说明通知似乎是如何引发问题的？ 因为我们仅使用通知发送数据。 不是通过从移动应用程序端读取特征来要求苛刻 它在所有其他器件上都可以正常工作。  

2) 2)即使我是使用非 TI 工具收集的、您也可以使用 Wireshark 轻松地进行解读。 我发送的屏幕截图来自 Wireshark 应用程序。 我们不需要任何插件来解释数据。 Wireshark 具有内置的 BLE 协议解释器。  

3) 3)我将与我的应用团队核实并返回。 由于我们的器件应每秒报告200个实时数据样本、因此我们希望以单个连接间隔发送尽可能多的数据。 恐怕阅读特征对 我们来说不是正确的解决方案。  

4) 4)我将检查并返回。  

最好

Lakshmi

您好 Clement、

我在有问题的电话上记录了 NRF Connect 日志。 我观察到、当应用程序尝试启用通知时、GATT 错误0x85生成并断开连接。 在其他电话上没有观察到这种情况。  

附件是 NRF 连接应用程序的屏幕截图。  

最好

Lakshmi

您好！

感谢您提到这一点。

GATT 错误0x85可能是由电话引起的-尤其是考虑到该问题仅在有限数量的电话中重现。 您可以查看以下主题以了解更多详细信息： https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1178303/cc2652p7-regarding-gatt-error-133-0x85

我希望这将有所帮助、

此致、

您好 Clement、

我通过使用 JTAG 进一步调试了固件的确切位置。 当 使用 MSG_BUFF_Not_AVAIL (0x04)返回时、我发现它在 HeartRate_MeasNotify 调用处挂起(由于使用 HAL_ASSERT_CAUSE_ICALL_TIMEOUT 置位)。

  当数据准备发送时、每10ms 我连续调用 HeartRate_MeasNotify 6次、直到该 API 返回非零值  

在这种情况下、在  发送前3个通知后、我从该 API 接收 MSG_buffer_not_avail。 (在使用其他手机时从未如此)  

附件是我的会话中的 CCS 调试屏幕截图、供您参考。  

有什么想法吗？  

最好

Lakshmikanth。  

 

您好！

MAX_NUM_PDU 使用的值是多少？

此致、

您好！

#define MAX_NUM_PDU     5.

最好。

Lakshmi

您好、Lakshmi、

为了更详细地解释我的推理、状态"MSG_BUFFER_NOT_AVAIL"通常意味着"没有 HCI 缓冲器可用"。

通常、这种错误是良性的、应用程序代码不应在这种情况发生时触发断言或挂起。 相反、我建议丢弃数据包并继续执行。

如果有足够的可用 RAM、您可能还需要尝试增大 MAX_NUM_PDU 的值。

如果您需要更多详细信息、请告知我们。

此致、

您好 Clement、

以下是我的观察结果；如果我错了、请纠正。  

 当 HeartRate_MeasNotify 返回 MSG_Buffer_Not_AVAIL (它总是连续第三次调用)时、出于某种原因、它不会将控件返回给被调用方。 因此 、HeartRate_taskFxn 调度程序正在丢弃 HAL_assert_CaUSE_ICALL_TIMEOUT；因此代码正在进入自旋锁。  

如果上述理论为真、如何在 HeartRate_MeasNotify 返回 MSG_Buffer_Not_Avail 时找到它出现的问题？  

请分享您的想法。

最好

Lakshmi  

您好、Lakshmi、

(请注意、我不知道代码库是什么样子的、因此我只能做出一些假设-很抱歉、指导不够准确。)

我想您有 HeartRate_MeasNotify 的源代码、不是吗？

在 HeartRate_MeasNotify 内、MSG_BUFFER_NOT_AVAIL 应由 ATT 函数返回(我想该函数会排队通知)。 理论上、该误差应传播到更高级别的代码、可能会触发无限循环。 确保不是这样、然后重新尝试排队通知。

此致、

您好 Clement、

我的应用程序中的更高级别代码不是无限循环。 它尝试发送6个通知。 如果收到错误、则返回。 此外、相同的代码也适用于其他安卓/移动版本。  

我的另一个问题是、我使用  simplelink_cc2640r2_sdk_1_40_00_45版本的 SDK 自定义了此应用。 这可能是原因吗？  

SDK 升级是否有帮助？

最好

Lakshmi

您好！

我强烈建议升级 SDK 版本。 此 SDK 无法再用于新的低功耗蓝牙认证(QDID 过期)。

此致、