[参考译文] CC3230SF：如何故意挂起系统以在 CC3230SF 上测试看门狗复位

admin

Other Parts Discussed in Thread: CC3230SF, CC3235SF

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1547161/cc3230sf-how-to-intentionally-hang-the-system-to-test-watchdog-reset-on-cc3230sf

器件型号：CC3230SF
Thread 中讨论的其他器件： CC3235SF

工具/软件：

尊敬的 TI 团队：

我目前正在使用 FreeRTOS 处理 CC3230SF 项目。我已经在Watchdog_RESET_ON模式中配置了看门狗计时器、并且看门狗在一个单独的任务中被清除 (watchdogTask)。正常运行时、一切正常、并且馈送看门狗 一致。

现在我想 有意模拟系统挂起 以测试看门狗复位机制是否按预期运行。

我面临的问题如下：

当我特意引入一个像一秒钟的故障调用initI2C()（失败但不会崩溃）时、系统不会完全挂起、watchdogTask仍然会运行、并且看门狗会继续馈送。
因此、即使主逻辑无响应、系统永远不会复位。

我的问题：

如何特意挂起系统 （例如，模拟死锁，无限阻塞，外设失速等）、防止看门狗被清除？
是否有任何已知的方法 导致外设导致的系统挂起 例如强制 I2C/SPI 或 UART 无限期阻止？
将Watchdog_clear()呼叫从单独的任务转移到我的中mainThread()、以便更有效地捕获应用程序挂起、这是否更好？
是否有任何最佳实践或 TI 建议的测试方法可供使用 验证看门狗复位行为 ？

最后、我正在寻找任何可靠的方法来强制系统挂起或死锁、以便可以观察看门狗是否正确复位 CC3230SF 器件。

提前感谢您的帮助和建议！

3 个月前

0 admin 3 个月前

TI__Guru**** 2466550 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

尊敬的 Muhammand：

感谢您在 E2E 上联系我们。

我们有一个示例、展示了名为“Watchdog"的“的看门狗函数（既复位看门狗，又触发看门狗超时）、位于此处的“examples\rtos\CC3235SF_LAUNCHXL\drivers"。“。如果您还没有、请看这个示例。在 I2C_INIT () 的情况下、watchdogTask 仍在运行并使看门狗计时器复位、这就是器件没有复位的原因。调用外设 API 时、如果存在返回值、您可以检查返回值是否成功、如果未正确返回、而 (1) 可能会引发器件复位。例如：

    i2c = I2C_open(Board_I2C_TMP, &i2cParams);
    if (i2c == NULL) {
        Display_printf(display, 0, 0, "Error Initializing I2C\n");
        while (1);
    }
    else {
        Display_printf(display, 0, 0, "I2C Initialized!\n");
    }

上面是 SDK 中的另一个示例、该示例位于 examples\rtos\CC3235SF_LAUNCHXL\drivers\i2ctmp116

TI 并未明确展示测试看门狗行为的最佳实践、但您采用的方法似乎是合理的。 watchdog_clear() 不需要与应用程序线程位于同一线程中。它可以在单独的线程中。希望这有所帮助。

此致、

Santhosh

Wi-Fi®︎（参考译文帖）

Wi-Fi®︎（参考译文帖）(Read Only)

[参考译文] CC3230SF：如何故意挂起系统以在 CC3230SF 上测试看门狗复位

我面临的问题如下：

我的问题：