[参考译文] CC3235SF：即使安装了看门狗、器件也会挂起

Jitendra、您好！

如果我理解正确、复位会修复此问题、但看门狗不会触发复位。 是这样吗？

在卡滞之前、您是否收到任何 Simplelink A-SYNC 错误事件？ 是否要在 simplelink 事件处理程序中打印错误消息以获取此类消息？

我们不熟悉有关看门狗的硬件问题。 重置计时器的过程可能仍处于活动状态。 请查看监视/看门狗功能(例如，只要看门狗被复位，就可以切换 GPIO)。 您是在中断内还是在低优先级任务内处理看门狗？   

问题是否与 OTA 更新相关(例如、在之后出现)？

BR、

Kobi

让我为您提供有关实施的更多详细信息。

系统中有5个任务。 一个是具有最高优先级的 simplelink 任务。 一个是看门狗任务第二高优先级。 和 REST 是较低优先级的任务。 看门狗任务负责监视其他任务并清除看门狗。 此任务每8秒使用一个周期软定时器来调用一次。 每个要监视的任务在进入执行前设置一个标志和时间戳、并在进入队列等待状态前清除该标志。 看门狗任务会检查执行标志、并检查任务执行的时间是否超过预期(挂起条件)。 如果发生这种情况、它不会清除看门狗并且会发生复位。

当所有任务都在等待时、器件进入 LPDS。 通常、看门狗任务是每8秒周期性唤醒器件以清除看门狗的唯一任务。 唤醒和进入睡眠模式是否会影响看门狗行为？ 从 LPDS 唤醒后、我是否需要反复重新初始化它？

现在回答您的问题：

是的、复位应该会修复此问题、但不会发生复位。 我已经测试了上述实现、以便在任何任务挂起时从闲置状态恢复。

我已经打印了 WLAN、套接字事件和简单链路事件。 但似乎没有一个。 但是、如果需要、我可以添加更多打印件。

看门狗任务在清除看门狗之前具有 UART 打印功能、并且当器件显示挂起状态时、不会打印任何 UART。 因此、我认为它没有执行。 UART 是否有可能在中间停止工作、我丢失了打印件？ 我可以在清除看门狗之前添加 GPIO 切换代码、但由于很少出现这种情况、因此很难对其进行监控。

此处不涉及 OTA。

您能解释一下电流消耗吗？ 通常情况下、器件在激活时的电流消耗为30mA、在 LPDS 模式下的电流消耗小于1mA。

当器件卡在此状态时、我可以探测晶体输出。 这会有帮助吗？ 我觉得看门狗不踢的唯一原因是看门狗停止了打勾。 这些引脚上的正常行为应该是什么。

电源由锂离子电池提供、稳定在3.9V。 但问题是否可能与电源有关？

看门狗 只需要慢时钟、应在 LPDS 期间保持运行。

50mA 可能意味着主机不会进入 LPDS。

我不确定看门狗逻辑。

如果低优先级应用任务将获得堆栈等待消息队列、则该标志将关闭、而更高优先级的看门狗线程将继续复位。 我可能错过了一些东西。  

再说一次、我不会怀疑看门狗硬件(直到您提出可靠的证明)。 类似的问题通常与看门狗处理中的故障有关。 UART 日志可能会由于各种原因而停止工作。 您使用的是哪种打印方法(Display_printf、UART_PRINT 或其他任何方法)？

BR、

Kobi

您好、Kobi、

看门狗只需要慢时钟、应在 LPDS 期间保持运行。

看门狗从40MHz 而不是32K 获取时钟。 对吧？ 进入睡眠状态时、40MHz 被选通。

自 TRM 10.1起

看门狗定时器模块支持以下时钟源：
•系统时钟(运行模式下为80MHz)

它在 LPDS 中进行门控、对吧？ 从睡眠 WD 返回后、应在没有任何配置的情况下恢复运行。 对吧？

还有一个观察结果。 电流消耗约为80mA。

我可以在设备处于挂起状态时从同一网络 ping 该设备。 NWP 是否有可能重新启动并恢复？

这种功耗建议在有源监听(53mA)和 MCU 有源(25mA)下的 NWP 为80mA。

我正在使用 NWP 配置的非持久设置、因此我相信它可以恢复、重新连接、并且不启用任何电源策略。

我不讨论 MCU 硬件。 我将介绍 cc3235所属的整个器件。 总体而言、该器件按照数据表的电流消耗和数据表的吞吐量正常工作。 因此、我觉得硬件没有问题。 我们已经为批量生产提供了一个提前期。

此致

您好、Kobi、

另一个更新。 下面是我的看门狗设置。

我已经通过按下按钮以 HWI 异常强制发送器件来验证它是否正常工作。

您能否指出上述 WDT 配置哪些可能会阻止 WDT 触发的情况？
我已禁用 WDT 测试模式。

尽快启动 WDT。

int main (空)
｛

    Board_initGeneral()；

     AS_Init_Watchdog()；

。

｝

另一个详细信息：我的应用代码进入 LPDS 状态。

此致

如果您可以对器件执行 ping 操作、则系统可能已启动、并且您的线程可能会重置 WDT (否则、您可能会看到 MCU 复位)。 我仍然不确定您的监控逻辑是否正确、

您可以通过不运行看门狗线程来检查 WDT 设置-查看它是否会复位 MCU。

您是否查看过看门狗示例？

您是关于系统时钟的。 看门狗不会在 LPDS 中计数。

您设置了什么触发器来退出 LPDS？

如果禁用 LPDS 会发生什么情况？

80mA 非常高、我不知道它的来源是什么。

在系统挂起之前、您是否正在执行任何特殊操作或出现任何异常的日志消息？

BR、

Kobi

您好、Kobi、

请检查内嵌的响应：

您可以通过不运行看门狗线程来检查 WDT 设置-查看它是否会复位 MCU。

是的、在上述条件下存在看门狗复位。 我已验证。

您设置了什么触发器来退出 LPDS？

GPIO 唤醒和看门狗计时每8秒唤醒一次。 看门狗周期为10秒。

如果禁用 LPDS 会发生什么情况？

我需要检查一下。

80mA 非常高、我不知道它的来源是什么。

我想我可以解释一下。 NWP 处于主动侦听模式、应用 CPU 处于某种运转状态。 但不确定系统是如何进入该状态的。

~50mA +~30mA

在系统挂起之前、您是否正在执行任何特殊操作或出现任何异常的日志消息？

不需要任何东西。 打印停止后，MQTT 代理会将设备标记为脱机，大约2-3分钟后。

现在、我将6个器件置于测试3下、启用 NWP 日志、其他器件仅启用应用程序 CPU 日志。

在固件中、我启用了重新加载值为10秒的看门狗。 如果所有任务 都正常执行、则每8秒唤醒一个任务以清除 WDT。

执行"正常"意味着每个任务都必须等待具有固定持续时间的状态、否则、任务将被假定为已崩溃。

我还启用了一个条件、在大约10小时后、即4500个周期的看门狗任务后、它应该强制创建看门狗复位。

日志中的观察结果很少。 其中3个卡死了。 3保持正常运行。

第一个在12小时后工作正常、但4小时后在日志中观察到复位。  PRCM_POWER_ON 复位原因。

第二个在1小时后卡住、更新的在10小时后未恢复 WDT 复位。

第三个在2.5小时后卡住、  10小时后从未恢复任何 WDT 复位。

第四个故障是在4小时后卡住、  10小时后从未恢复任何 WDT 复位。

Firth 一个正在工作、但有2个复位、一个在8小时后、另一个在5小时后、具有相同的复位原因。

第六个正常工作、10小时后出现 WDT 复位、这是预期的。

我能够 ping 通所有设备的 IP、它们在路由器的 DHCP 列表中可见。

我有前3个器件的 NWP 日志。 我可以通过电子邮件共享的内容。

我也可以通过电子邮件共享部分代码。

这目前正成为一个主要的障碍。  

此致

您好、Kobi、

我在禁用 LPDS 的情况下对5个器件进行为期24小时的测试。

所有这些都按预期工作。  

我觉得 LPDS 会搞砸一些东西。 我觉得代码执行正确。 如何调试问题？

TI 的一些产品可以在这里为我们提供帮助吗？ CC3235看门狗有点复杂、因为它不是从慢时钟计时的。  

看门狗和 LPDS 是否提供任何参考示例。

此致

我们清理了代码并删除了编译时警告、还重新处理了 LPDS 和看门狗代码。 问题在某种程度上有所减少，但问题仍然存在。  

是否有任何调试方法？

使用特定的大量芯片会有什么问题吗？

[i]芯片：0x31100019
[i] MAC：3.1.0.5
[i] PHY：3.1.0.18
[i] NWP：4.3.0.5
[i] ROM：8738

因为在我们的最新版本中、我无法重现此问题。

此致

是的、我根据建议进行了更改。 现在的实现非常直接。

我们已经在测试中加入了更多器件。 但是、由于问题是随机发生的、我们很难进行测试。

我想共享部分代码以了解进入 LPDS 和退出 LPDS 的情况。 如何与 TI 的某人私下进行此操作？

我们处于产品的一个非常关键的阶段。 当一切准备就绪时、这是我们无法发货的唯一问题。