[参考译文] CC2652R：中断时帧挂起不正确

您好！

您可以在最新的 CC2652R SDK 上运行该测试吗？
https://dev.ti.com/tirex/explore/node?node=A__AEIJm0rwIeU.2P1OBWwlaA__com.ti.SIMPLELINK_CC13XX_CC26XX_SDK__BSEc4rl__LATEST

其中可能已修复了15.4 Stack 库中的问题。

谢谢！
Toby

我已经测试了7.40和7.41、两者都没有解决。

我注意到7.41中的源代码中有一些相关的更改(但我在 changelog 中看不到关于它们的任何更改！) 但是、这些都没有帮助。

从7.41.00.17开始：

您能否从在 TI Launchpad 上运行的 TI 示例开始分享复制步骤？

这是 Zigbee 示例吗？

这是 ZNP。

复制它的最简单方法是：

 - 增加 Mac 重试次数,以增加从 ZED 丢失 ACK 的可能性。

 -放置几个 ZED 传感器在20-30 LQI 的距离

-设置常规轮询控制(例如10分钟)

-让监听器运行

理想情况下、ZC 将错过来自 ZED 的 MAC ACK (例如、由于冲突)、这将说明这一事件序列。

我们每天会获得1到2个传感器网络、其中 ZED 位于大约20-40 LQI 附近

我们已确认原因。 当 ZC (ZNP)在一个中断的发送过程中、帧等待不会被发送。 帧等待(通过 srcmatch 卸载到硬件)可能会在数据包出队以进行传输时清除、而不是在 txComplete 应有的状态下清除。 在所有其他情况下、帧挂起是正确的。

感谢您分享这些详细信息。

通常、blob/lib 修复程序将在接下来的1-2个 SDK 中修复。

器件是否从该状态中恢复？ 似乎在下一个轮询周期中、器件仍会轮询 ZC。

我将向我们的 Z-Stack rnd 团队提交请求单。

将在5个工作日内更新。

ZED 在下一个 Data Req (MAC Poll)周期时正常。 然而、这种情况也有机会重复。

我们使用的一个 ZED 对于触发重新连接具有高灵敏度(似乎是三个失败周期)。  只要这种重复的可能性很小、就可能发生。 我们认为它在车队中得到了观察。

明白了、我已经向我们的 Z-Stack rnd 团队提交了 TT、并将在5个工作日内更新。

我还没有听到。

不过、我认为此处有足够的细节供堆栈开发人员进行研究。 我现在不能提供时间表。

是否有任何更新？

还没有,我已经在我之前提交的 TT 再次询问。