[参考译文] CC3220SF：在某些情况下尝试重新启动时、器件挂起

admin

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1303405/cc3220sf-device-hangs-when-attempting-to-reboot-under-certain-conditions

器件型号：CC3220SF

我们的系统使用 TI MQTT 库连接到后端。

我们创建了一个用于重新启动系统的函数、在某些情况下我们会调用该函数。功能代码如下所示。当系统启动并调用该函数时、它会按预期重新启动所有内容。
但是、当我们在连接到 Wi-Fi 和 MQTT 后端之后调用该函数时、所有内容都挂起、需要使用复位线路重新启动。

我们需要一种可靠的重启机制来从某些故障场景中恢复、但这是不起作用的

void system_reboot (void)
{
   sl_Stop (100)；
   MAP_PRCMHibernateIntervalSet (330)；
   MAP_PRCMHibernateWakeupSourceEnable (PRCM_HIB_SLOW_CLK_CTR)；
  MAP_PRCMHibernateEnter();
｝

系统详细信息：

RTOS：FreeRTOS
SDK：simplelink_cc32xx_sdk_6_10_00_05

1 年多前

0 admin 1 年多前

TI__Guru**** 2482225 points

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

您好！

如果 SimpleLink 驱动程序(主机驱动程序)由于某种原因(例如由于其他代码的堆栈溢出)而崩溃，则不应在重新启动过程中调用 sl_Stop ()。您应该在不调用 sl_Stop ()的情况下调用休眠代码。但是、请确保没有正在进行的 sFlash 写入操作。这可以通过代码的逻辑来确定。因为如果在 NWP 对 sFlash 执行写操作时重新启动(没有 sl_Stop()且超时合理)，可能会损坏该文件。

1月

0 admin 1 年多前

TI__Guru**** 2482225 points

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

我可以避免调用 sl_stop、但问题是如何也重新启动 NWP、因为可能出现了问题。我正在寻找类似于复位引脚的复位。

我意识到、正如您所说、调用 sl_stop 失败是因为它取决于 NWP 对该命令的行为良好(在某些情况下不是这样)。

闪存写入没有问题。

0 admin 1 年多前

TI__Guru**** 2482225 points

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

您好！

使用 PRCM 休眠调用重新启动正常。如果不添加外部硬件来控制复位引脚、则没有更好的方法来重新启动整个 SoC。

对 NWP 的依赖性不存在大问题。问题是您的代码或在应用处理器上运行的其他代码由于某种原因损坏了内存。在这种情况下、行为可能是不可预测的。使用看门狗可能会解决一些情况、但不会解决100%的情况。

1月

0 admin 1 年多前

TI__Guru**** 2482225 points

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

通常在我们的示例中，我们使用 MAP_PRCMHibernateCycleTrigger ()对 MCU 进行软复位。

建议在禁用中断的情况下调用它、

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

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

[参考译文] CC3220SF：在某些情况下尝试重新启动时、器件挂起