[参考译文] CC2340R5：发送数据包、回调函数有时不执行&&#39；不执行

尊敬的 Senjin：

您能否量化"极罕见的情况"、因为在这种情况下、每千个数据包中有 x 个？  重新创建问题是否需要任何网络条件(嘈杂的环境、繁忙的无线电信道、网络中的多个设备等)？  是否有任何可以避免回调失败的补救措施、例如增加数据包间隔、减少每个数据包的数据字节、提高串行端口速度/队列、禁用串行端口等？  您是否能够实施一种权变措施、使您能够检测丢失的回调(例如发送计数器或计时器到期)、从中可以记录回调失败并释放内存？  您认为、使用默认 TI 示例重现此行为的最佳方法是什么？  您是否使用最新的 v8.40.02.01 F3 SDK 来观察此行为？

此致、
Ryan

您好、Ryan、

1、发送20k 数据包时可能会遇到此问题。

2、 不清楚无线环境和信道是否相关。 我在办公环境中测试了它 、只有一个 ZC 和一个 ZED。

3、 不是补救措施现在已经确认

4、 我认为没有必要实施变通办法、因为当出现此问题时、它将继续发生、即使我释放内存也没有意义。

5、 我可以向您发送我的 CC2340 ZED 缩减版本和 CC2652 ZC 十六进制固件的源文件、以便您可以轻松进行测试来重现此问题。 您需要它吗？

6、 我正在使用 v8.40.02.01 F3 SDK、并已更新您通过电子邮件发送给我的补丁。  

1.这是否意味着 问题将在一致的数据包计数(即20k)下发生、或者是否比此值早/晚发生？

3.请考虑尝试一些我的建议,以产生更多的意见。

4、感谢澄清,我之前还不明白,问题在第一次出现后会继续连续发生。

5.我希望  CC2340 Zed 源 代码的简化版本 能够进一步调试该问题、但这是否需要连接 PC 主机才能进行测试？  我更喜欢独立的 CC2340R5 ZED + CC2652R ZC 环境,该环境不依赖于 PC 主机进行复制。

此致、
Ryan

您好、Ryan、

1、它随机发生在20k 个数据包之前、不能确定何时发生。

3、 有时间我会进行测试。  

5、是的、需要 PC 主机、我可以提供给您。  如果您需要独立的 CC2340R5 ZED + CC2652R ZC 环境、我会在修改代码后将其提供给您。

您好、Ryan、

我需要更正一条消息、指出发送200k 个数据包可以重现问题、而不是20k。  

在今天的测试中、我将传输间隔从50ms 增加到了80ms、将数据包大小从64个字节减少到6个字节、并将串行端口波特率从115200提高到230400。 当发送大约170k 个数据包时、问题仍然出现。 其他测试仍在进行中、我会尽快更新

您好、Ryan、

这可能与我未使用 v8_40_02 SDK 中的 zboss_r23\include 文件有关。  当我基于 v8_20_00 SDK 进行开发时、我将 zbos_R23\include 文件复制到了我的工程文件夹中。 但是、当我将 SDK 更新到 v8.40时、并没有及时更新此文件。  我需要更多时间进行验证。

您好、Ryan、

不幸的是,我不得不告诉你,即使我更新了包含文件,我仍然遇到这个问题,当我测试超过6个小时。

注意：我在屏蔽室测试、不包括无线信号干扰。

我计划根据 onoff_switch_LP_EM_CC2340R5_freertos_ticlang 的源代码再次进行修改和测试、使 zed 持续发送开/关切换请求。 在此期间、CC2652P ZC 不发送数据。
我已将源代码添加到附件中。 如果你有时间,你可以一起测试。

注意：Rx Always On 应设置为 true。

e2e.ti.com/.../5810.on_5F00_off_5F00_switch.zip

由于提供了这一信息,很遗憾,我方面的进一步测试将 推迟到 下周。

此致、
Ryan

您好、Ryan、

我使用自己的 CC2340 ZED 应用来测试以 50ms 的间隔向 CC2652 ZC 发送数据包、并且 ZC 没有向 ZED 发送数据。 测试持续了两天半,没有任何问题。 如果 CC2340 Zed 和 CC2652 ZC 相互发送数据时、会出现问题。

因此、我怀疑它与 CC2340的接收和处理逻辑有关。 现在、我将 与您共享测试源代码和监听日志。
其中、CC2652 ZC 基于 simplelink_cc13xx_cc26xx_sdk_8_30_01_01、示例为 zc_light_CC1352P_2_LAUNCHXL_tirtos7_ticlang。

CC2340 Zed 基于 simplelink_lowpower_f3_SDK_8_40_02_01 (onoff_switch_LP_EM_CC2340R5_freertos_ticlang  的示例)、请注意 RX alway on 需要设置为 true。

e2e.ti.com/.../code-and-log.zip

感谢 Senjin 提供此详细信息。  根据您的观察结果、假设 CC2340R5 ZR 工程中也存在此问题是否合乎逻辑？  工程是否必须在 SysConfig 中使用 DUAL ZED + ZR 配置？  此外、CC2340R5 ZED 灯是否仅以50ms 的间隔接收到来自 ZC 开关的开/关消息、是否会发生问题？

感谢您耐心等待、我们将此行为隔离到 F3 SDK Zigbee 栈的特定层。

此致、
Ryan

您好、Ryan、  

我在 SysConfig 中将器件设置为仅 ZED、RX 始终开启、我目前尚未验证 ZR 是否有任何问题。
我需要澄清的是、我还不确定是否可以使用我提供的源代码重现此问题、该源代码与我之前发送私有 ZCL 命令的测试不同、我也在进行测试。

我无法每50ms 使用 F2 SDK ZC 开关向 F3 SDK CC2340R5 Zigbee 照明发送开/关切换命令、而不管它是非休眠 ZED、ZR 还是组合映像。  在这种情况下、CC2340R5不会向 F2器件发送 ZCL 消息、而是仅接收。

感谢您提供的测试代码、我已尝试按照提供的说明进行评估、但在20分钟后无法复制(这应该相当于超过20k 数据包故障率、 20个数据包每秒1000秒或16.7分钟、才能传输20k 数据包)。  

因此、我很难重现这个问题。 请建议我可以进行的任何更改、以帮助模拟您遇到的挑战。

此致、
Ryan

您好、Ryan、

我想纠正这个问题：连续20分钟测试不足以重现问题。 根据我最近的实验,这个问题需要6个多小时才能重现。  此外,我使用了这个测试代码昨晚测试约14小时,今天上午我也重现了这个问题。 通过 Sniff 日志、我观察到 cc2340 Zed 已停止发送开/关命令。  

感谢您澄清 Senjin,这是更接近失败在432k 数据包,而不是20k 数据包,这是我的原始测试基于的假设.  我需要进行长寿测试、或许需要进行夜间测试、以确定是否可以观察设置中的行为。

此致、
Ryan

尊敬的 Senjin：

我确认可以复制类似的行为并在我这边观察到问题、请留出更多时间让我进一步调试并与 Zigbee 研发团队同步。

此致、
Ryan