[参考译文] CC2340R5：在高负载条件下传输数据时、系统偶尔会停止

嘿森晋、

感谢您报告这一点、我认为 TI 迄今为止已对 CC2340R5 Zigbee 解决方案进行了应力测试。  对于 ZR 节点、是否也会发生这种情况？  您可以 从  exception_handlerSpin 调用 PMCTLResetSystem 以重置器件并从崩溃中恢复。

此致、
Ryan

感谢您的答复。 是的、ZR 也会如此。  

Zigbee 研发团队正在不断进行调查、我会在有可用更新时告知您。

此致、
Ryan

尊敬的 Senjin：

Zigbee 研发团队将持续调查这种行为。  您的应用如何 每50ms 触发一个数据包？  您是 使用 ClockP TI 驱动程序、 ZBOSS 调度程序 API 还是其他程序？  您能否共享根据现有示例修改的应用文件、TI 可以为其复制此行为？

此致、
Ryan

您好、Ryan、

我使用 PC 应用通过 UART 向 CC2652P ZC 发送数据包。 然后、ZC 首先将数据包存储在队列中、从队列中检索数据包、并将其发送到 CC2340R ZED。 ZED 从 ZigBee 网络接收数据包、并通过 UART 将其传输到 PC。  两个应用同时发送间隔为50ms 的数据包。  

我只能共享用于发送的相关源代码、并将其添加到附件中。  

e2e.ti.com/.../CC2340R-send-packet.zip

感谢您提供更多信息。  遗憾的是、发送源代码对问题复制的作用不大。  我还想知道此问题是由 Zigbee 堆栈还是 UART 实现引起的。  您是否能够禁用 UART 或绕过其使用、以确认其不是导致问题的原因？  您能否尝试增加波特率或缓冲区大小、以观察这是否可以减轻或延迟故障？

Zigbee 研发团队已经确定了一种竞态条件、在这种条件下、如果应用程序通过异步事件(例如 ClockP)或除 ZBOSS 调度程序之外的任何内容分配缓冲区、则可能会发生一些缓冲区损坏、导致异常。  他们计划在即将推出的版本中进行更改以解决此问题。  但是 、尚不清楚这是否能解决您的用例问题。 如果 您的应用程序未检查 ZBOSS API 的返回代码、请纠正此问题、并告知我们是否返回了任何错误代码。 另请确保在 Zigbee 应用中正确释放缓冲器

此致、
Ryan

您好、Ryan、

何时会发布下一版本的 SDK？ 下一个版本发布后、我将再次对其进行测试。 如果出现崩溃问题、我会根据您的建议进行验证。  我现在还有其他优先工作要处理。

尊敬的 Senjin：

下一个 SDK 版本计划在4月底发布、但我们可以与您离线合作、在本周年底之前提供更新的库进行测试。  如果有电子邮件可用、我将通过电子邮件与您联系。

此致、
Ryan

您好、Ryan

提供更新的库是个好主意、但我希望您的团队能够解决孤立节点无法在提供之前一起睡眠的问题。 谢谢

您好、Ryan、

如果这个周末无法解决低功耗问题、请给我一个更新的库、以先验证崩溃问题。  

您好、Ryan、

我试了半个小时,没有崩溃。 这似乎是解决了。 你已经帮了我很多。 我明天会做更多的测试,如果我有任何问题,我会咨询你