[参考译文] CC2651P3：终端器件丢失网络信息

以下是监听器捕获文件的链接：

www.dropbox.com/.../2023-09-25_captura_4_dias_quinta_a_segunda.pcapng

您好、Tiago、

感谢您提供监听器日志。  仅 当 超出 MAX_DEVICE_UNauth_timeout 时、应用程序内才会恢复出厂设置(您提到的 TCLK 交换故障情况)、器件需要离开网络而不重新加入(leave 命令)、或由应用程序 UI 调用(UART 终端菜单或启动时的 BTN-2)。  您已经介绍了前两个选项、是否禁用了 UI 或以任何方式更改了此功能？

这些器件的不稳定行为表示 NV 存储器可能被损坏。  您是否必须强制新工厂条件重新裂变这些设备？  否则、  在发生故障后、您需要执行哪些具体步骤才能让他们重新加入网络？  您在什么电压下为这些器件供电、该电压是否会波动、以及您是否实施了 低电压检测？  此外、您的器件如何从应用进入关断模式？  

此致、
瑞安

您好、Ryan、

UI 已禁用、我在广播中看不到任何"重新加入"设置为 false 的留言、因此我认为这两个选项都可以 被丢弃。

关于您的问题、是的、我必须强制 换一个新的工厂条件来使器件停止工作。 该器件由 CR2032锂电池供电、我认为电压稳定、但 还没有实施 低电压检测。 我不认为是原因造成了问题、但我会研究一下并实施低电压检测、以使系统更加稳健。

我正在强制器件进入 SHUTDOWN 模式。  我没有考虑内存损坏的可能性是一个可能的原因,但你的问题让我认为,通过强制关机,我可能会导致 NVS 损坏,如果堆栈正在写入它的时候,我强制关机。 我将使用 TI-RTOS 电源管理例程来纠正此问题、以避免在执行其他一些活动时进入 SHUTDOWN 模式。  

总之、我还将 并行调查 TCLK 交换故障。  什么情况会导致 MAX_DEVICE_UNauth_timeout 过期？ 只有射频通信故障可能导致这种情况？ 例如、如果该器件在该处理器的中间被孤立、这是否会导致出现这种情况？ 什么会在调试的器件中触发新的 TCLK 交换程序？

谢谢！

正如您知道的那样、如果电池下降到低于2200mV 的范围或者为器件供电不足、那么这肯定会导致 NV 闪存写入故障并因此损坏 NV 存储器。   

Unknown 说：

如果堆栈在上面写入，当我强制关闭时，我可能会导致 NVS 损坏

这无疑是一个问题、我强烈建议使用 TI-RTOS 电源管理 例程和 功率 TI 驱动程序。

 仅当加入设备从 ZC 信任中心请求 TCLK 更新并且在10秒内未收到回复时、才会发生 MAX_DEVICE_UNauth_timeout。  这只会在原始联接过程中发生、不会重新联接、因此我认为这不是您遇到的问题。

此致、
瑞安

我检查了我的代码以进入 SHUTDOWN 模式、然后使用 Power_SHUTDOWN (0、0)。 其文档说明此例程应遵守由栈或任何其他使用电源管理的驱动程序设置的任何约束。 所以我不认为我破坏 NVS 去关闭,对吗? 我的代码如下：

在操作过程中、电池张力几乎降到3V 以下、在我的测试中绝不低于2.9V。 我将实施 低电压检测、但 我认为 现在不存在这个问题。

我将尝试确定 我的问题是由 出厂时新的重置还是 NVS 损坏引起的。 对于恢复出厂设置、我将尝试找到触发位置并放置一些代码以通知我是否执行了该代码路径。 对于 NVS 损坏，我认为我需要在事件发生后检查 NVS 内容。  对于如何识别 NVS 腐败、您有其他建议吗？

回想一下、从应用任务中进入 SHUTDOWN 应该是安全的。  您很可能在之后进入空白 while 循环、因为在进入 SHUTDOWN 模式后不应执行任何其他操作、但我不能期望应用程序超过 Power_SHUTDOWN。  您还可以考虑使用 OsalPort_enterCS 来进入关键段(本质上是禁用硬件中断)。  NV 损坏难以识别、因为预计闪存区域在操作期间会发生变化以应对 网络更改、因此除非解析整个区域以获得进一步的上下文、否则将不会注意到损坏的条目。  TI 提供了 网络克隆指南 、可以为您提供进一步的提示。  感谢您提供示波器读数、如果可能、在发生故障时准确采集器件的相同信息将会很好。  虽然我认识到这项任务的复杂性,因为很难重现这一行为。  找到一种轻松重现问题的方法来进一步确定哪个变量直接导致该问题非常重要。

您可以 从 bdb.c 中断打印日志或将打印日志添加到 bdb_LocalAction 以进行 UI 出厂新重置 App_Reset、否则可从 ZD_app.c 监视 ZDstrategerStart 使用情况。  您应该能够确定在任何时候应用程序是否调用 Factory new、但正如您所说的、您"必须强制一个 工厂新条件来使设备重新商用"、似乎更有可能涉及 NV 损坏(如果不是完全涉及其他情况)。

此致、
瑞安

您好、Ryan、

我发现了一种容易重现的序列、在该序列中、终端设备会丢失网络信息。  我不是100%肯定我过去的测试所发生的问题都是这种情况所造成的，但我认为这条调查的道路是 有希望的。

首先、我发现可在终端设备上禁用关断并启用 UI 来执行此操作。 使用关断可以阻止或降低问题的可能性、但我认为它不能完全消除问题。  我认为 UI 与该序列无关。  我只使用一个协调器和一个终端设备。 触发此问题的完整序列如下：

1.打开协调器和终端设备。

2.在协调器上打开网络并使用 UI 调试终端设备

3.终端设备已调试并按预期工作。

4.关闭协调器并点击终端设备  

5.终端设备已连接 并尝试发送消息，但由于协调器不响应，因此重试次数很多，并进入孤立状态。

6终端器件检测到孤立状态、有时会 在重试间隔为1s 时尝试重新加入(我 为此使用 Zstackapi_BdbRecoverNwkReq)。

7.打开协调器并在重新启动后应答信标请求

8.终端设备发送一条重新加入消息，但未加密，这会触发一个未授权 重新加入

9 . Unauth REGIN 会在终端设备上触发一个10s 计时器、当该计时器过期时、会重新启动设备并清除其网络信息(ZCD_STARTOPT_DEFAULT_NETWORK_STATR)

10.终端设备开始发送许多数据请求消息、并持续10秒、直至计时器过期、从而清除所有网络信息

11.为了重新连接到网络，我需要重新传输终端设备。 OBS：我之前说过、我每次都需要进行一次"重新出厂设置"、但在这个序列中不是必需的、我想我是在出现问题的器件上进行的、而不是仅仅尝试进行重新组装。  

观察结果：

-正如我说过的,问题出现在硬网络情况下。 这可能会在不关闭协调器的情况下触发问题。

-如果我在计时器过期之前手动重启终端设备,它将返回到网络并正常工作,这表明终端设备未处于无法恢复的状态。

-我可以在启用关机的情况下触发这种情况。 这会有点困难、因为我需要让器件连接到协调器、然后关闭协调器、再打开它、而且整个序列必须发生而器件不会关断。

-即使我可以触发的情况下关闭启用,过程不会直到结束,因为设备在10s 计时器过期前关闭(如在手动复位)。 我不能让它直到结束,但这并不意味着没有发生这种情况。

说了这句话、我有一些问题：

- 什么是触发取消授权重新加入? 多个信标请求无应答？ 如果是、我应该怎么做？ 我该如何避免呢？

-即使触发了取消授权重新加入,为什么设备无法从它恢复?

-我知道这个简单的序列,触发这个问题,但可能存在更复杂的序列,也触发它。 在这样的情况下我是否应该丢失 NWK 信息？ 我做错了吗？ 在任何情况下都可以通过某种方法来阻止它？

相关代码分析和监听器捕获：

步骤8在 ZD_app.c 中的 App_Process Joordi 中触发以下代码块(红色箭头)。

计时器会在10时到期、并在 ZD_app.c 中的 ZD8p_EVENT_LOOP 上触发以下事件

解释标志 ZCD_STARTOPT_DEFAULT_NETWORK_STATRE 的作用的注释：

监听器捕获注释了完整的事件序列：

重新加入消息未加密触发未授权重新加入。

已启用关断功能的器件中重新生成的序列。 计时器到期前它会关闭、因此不会出现问题。

如有必要、我可以发送监听器捕获文件。

谢谢。

我将  BDB_ARTRING_UNSECURE_REGIN 更改为 FALSE、将 BDB_MAX_SECURE_REGINTRIGN 更改为255。 使用这个新配置、 我无法重现问题。 我将继续进行开发。

 将来、我想 调查 ZED 为什么忽略了 ZC 中的传输密钥、因为它可以指示代码中的一些其他问题、在某些不同的情况下可以触发。

更改 DEV_END_DEVICE_UNauth 的应用程序行为以在不擦除 NV 信息的情况下重置器件也可能是有效的防御策略。

感谢您的帮助、Ryan！