[参考译文] CC1352P：当 TX 数据队列中有大量消息时、具有15.4 Stack 和自定义 phy 的收集器变得无响应

嗨、志勇：

感谢您发送编修。 我们已经发布了 SimpleLink F2 SDK 8.30、因此如果您可以对此进行测试并查看此版本中是否仍然存在问题、我可以迈出一步。 我下周还会将此问题提交给软件开发人员。

1.您使用的是信标模式还是非信标模式?

2.发生这种情况时,有多少设备连接到收集器?

3.您使用的是哪个 RTOS 和 Compiler 选项？

谢谢、

Marie H

尊敬的 Marie：

感谢您的答复。 要回答您的问题：

1)无信标模式,它似乎是唯一兼容自定义 phy 的模式

2)我在具有18个和20个传感器节点的网络中观察到了这种行为,但在具有< 10个传感器节点的网络中观察不到这种行为。

3) TI-RTOS7、TI Clang v3.2.2

我会尝试使用新的 SDK 和其他方法来控制 TX 队列大小。 问题是这似乎是随机发生的。 发生这种情况时、CC1352P 的射频部分才会无响应。 另一个处理 GPIO、UART 外设等的内核可以正常工作。 因此、如果可能、很难由外部 MCU 进行管理。

此致、

志勇

嗨、志勇：

在8.30 SDK 中、我们还添加了一个日志记录工具、用于在 TI 15.4-Stack 中启用日志。 也许这可以帮助我们了解收集器上发生的情况。  

如果您认为 TX/RX 数据队列与问题相关、那么减小它们可能会使问题发生得更频繁、从而使调试变得更容易？

(在 RX/TX 数据队列溢出的情况下、我希望收集器将错误返回到应用程序、并可能丢失一些数据包、但不会无响应...)

谢谢、

Marie H

BTW 以下是一个 SimpleLink Academy 实验、可指导您将日志记录添加到工程中：

https://dev.ti.com/tirex/explore/node?node=A__AUtBCHw9KYI99xItuPjn4w__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST&placeholder=true

谢谢、

Marie H

尊敬的 Marie：

感谢您提供有关新增日志记录功能的提示。 我将看到是否可以将其添加到调试中。

同时、您能否建议如何计算增加 TX/RX 队列大小所需的 RAM？ 我的猜测是、这可能与 CC1352P 上的有限 RAM 有一定关系、因为我们在传感器节点< 10的较小网络中从未观察到这个问题。 如果确实如此、我假设我们可以通过切换到具有更大 RAM 的器件(例如 CC1352P7、CC1312R7或 CC1312R4)来解决/改善问题。

此致、

ZL

尊敬的 Marie：

您是否曾从 SW 团队那里听到过该问题？

我想报告的是、我们在包含 CC1312R/SDK v7.4和15.4 Stack 的无线电的大型网络(采用跳频模式)中也观察到了类似的问题。 当收集器无线电上的 TX_DATA 队列大于16 (仅为任意报告阈值)时、部分但并非所有传感器节点可能(并非总是)在获取跟踪消息时遇到问题、因此会成为孤立状态。这与无线电处于非信标模式和自定义 WB-DSSS 的网络不同、在 NB/Custom phy 网络中、当发生这种情况时、所有传感器节点都将成为孤立状态、并且在收集器重置之前无法重新连接到收集器物理层。

希望这将帮助您的软件团队调试该问题。

此致、

ZL

嗨、志勇：

您能否捕获这种情况的监听器日志？ 我会非常有趣的事情正在发生在空中:是否孤立的传感器正在尝试连接,收集器是否能够接收 PAN AS ,是否在连接阶段发生了什么。

谢谢、

Marie H

尊敬的 Marie：

捕获任何监听器日志都将非常困难。 这些受影响的网络在客户端的站点上运行、这种情况只发生了几次并且是随机发生的。 另外,我上次检查时,嗅探器工具不支持自定义 phy ,并且 FH 网络在数十个不同的通道上运行。

从收集器无线电在几分钟内重新启动这一事实来看、一旦整个系统下电上电、另一段时间在外部 MCU 切换 RESET 引脚后重新启动、所有传感器节点都能够(重新)加入网络、我相信问题仅出在收集器无线电上。

希望这对您有所帮助、

ZL

嗨、志勇：

您是否幸运地通过从收集器端发送更多数据包来触发此问题？ 或者您是否不再认为它与堆/TX 缓冲区有关？

谢谢、

Marie H