[参考译文] 编译器/CC3220MODA：有关在 CC3220中使用看门狗的查询/最佳实践

团队、

感谢有人优先帮我解决这个问题。

此致、

Zac

您好 Zac、

首先、我建议您阅读 TRM 的第10章(http://www.ti.com/lit/ug/swru465/swru465.pdf)。

看门狗示例未针对 CC3220实现进行优化(该示例在 CC3220和其他支持其他看门狗机制的 SimpleLink 器件之间共享)。

在 CC3220中、一旦超时到期、就会调用回调(ISR)。 看门狗将继续计数、直到第二次到期、然后自动触发复位。

这意味着您可以使用回调清除看门狗(在执行一些自检以验证所有线程是否正常工作之后)。  

您的问题答案：

1.保护初始化代码是一个好的做法，但如果初始化序列比超时时间长，则需要注意。 如果您使用回调来检查代码中的某些状态/标志、则应提前准备这些状态/标志。

2.看门狗线程优先级(如果使用)应该是最低的。 堆栈大小取决于您的实现方式。

3.您可以将超时时间增加到53.5秒(同样，它将对超时进行两次计数，直到重置发生)。 当然、最佳值取决于实现情况(您需要确保低优先级线程被调用、或者由看门狗 ISR 维护的状态在所选间隔内更新)。

4.不 实际上、这并没有针对 CC3220看门狗机制进行优化(在这种情况下、如果您将超时设置为5秒、则它将在 while 循环中再停留5秒、等待复位)。    

5.有许多方法是可行的。 您提到的线程可以是看门狗低优先级线程。 或者、您可以创建一个周期性运行的更高优先级线程(睡眠时间少于观察间隔、然后检查状态并清除看门狗)。  您还可以使用 ISR (callabck)执行检查并清除计时器。

6.这只是一个例子

7.否

8.第二次超时后、MCU 将复位。

9.没有我们所熟悉的问题。

BR、

Kobi

您好！

只是对第9点的评论。 我知道看门狗发生故障的至少两个原因：

• 主时钟崩溃时的情况。 这可以通过触摸 CC3220 LaunchPad 上大约40MHz 的 XTAL 来进行仿真。 在本例中、CC3220SF 芯片将"永久"冻结。 但 MOD 的影响要小得多、因为 XTAL 位于金属罐内。
• 一旦 CC32xx 器件上的 WDT 启动、则无法将其停用。 但 WDT 使用主时钟、该时钟由 PRCM 外设进行门控。 这意味着时钟发生器 WDT 可以被禁用、这可以有效地停用 WDT。 但是、您不太可能通过软件无意中实现这一点。

1月

非常感谢 Kobi。 尽管设置了看门狗、但在少数系统中 WDT 复位并未按预期触发。

我的看门狗实现如下-我为每个线程使用一个全局变量、每个线程保存上次运行时间戳(整数)、并且该时间戳将根据一些周期性运行的线程活动进行更新。 kicker 线程根据某个阈值检查所有这些全局变量、并且仅在时间戳有效时清除 ISR。 我意识到线程间共享变量由于读取-写入竞争条件而不安全、 但是、由于我们更新的是整数时间戳、因此出错的概率可能是很小的、即使发生错误、也会导致 WDT 复位或在下一次迭代中正常运行(假设)。 因此、剩下的可能性是 WDT 可能出现故障或时间戳变量突然出现错误(损坏或其他问题)。

请在下面找到我的评论。 感谢进一步的帮助。

1. 因此，这意味着看门狗不一定需要在分离的线程内启动，rite？
2. 好的。 由于我从主系统本身调用看门狗、我不确定是否可以降低优先级。 这是可以接受的吗？
3. 好的。
4. 好的。 我当前的实施方案只有1{}，我希望这不会产生任何副作用。
5. 我需要在看门狗复位期间执行一些文件操作、因此使用了单独的线程而不是 WDT ISR。 在我的实现中、我已将此设置为具有最大优先级、因为我需要无论其他线程状态如何都执行文件操作。
6. 所以我不需要在我的实现中使用 Power_disablePolicy()和 Power_enablePolicy()？
7. 好的
8. 好的
9. 好的。  

此致

Zac

谢谢 Jan、

在我们的场景中、这两个条件都不是预期的、因此我不确定它为什么失败。

此致

Zac

您的意思是"在少数系统中、WDT 复位未触发"？ 系统之间的区别是什么？

是否调用了回调(ISR)？  

您是否检查是否没有发生清楚的情况？

看门狗基于硬件(如说明)、可轻松进行验证(例如使用示例)。

BR、

Kobi   

您好、Kobi、

这些是安装在客户位置的模块、它们具有类似的 h/w 并运行相同的代码。 看门狗的实现方式是、如果任何线程发生故障或如果 MQTT 连接无法在重试6小时后建立、则不会调用看门狗清除、这将导致 MCU 复位。 这在开发过程中经过测试并正常工作。

然而、在生产中运行的50个器件中、有3个在4天或5天内未建立 MQTT 连接、它们未按预期复位、我们不确定发生了什么错误。 我们也无法从这些系统获取任何日志、在我们的开发过程中没有出现任何问题。 因此、我们将分析实现以了解代码中的任何异常。 感谢你的帮助。

您能评论一下这些问题吗？

此致、

Zac

您好、Kobi、

感谢您能帮我解决我的问题。

此致、

Zac

您好 Zac、

有什么疑问？ 您的所有问题都有答案、缺少什么？

BR、

Kobi

您好、Kobi、

请查找以下问题(继续回答初始问题)。

1. 因此，这意味着看门狗不一定需要在分离的线程内启动，rite？
2. 好的。 由于我从主系统本身调用看门狗、我不确定是否可以降低优先级。 这是可以接受的吗？
3. 好的。
4. 好的。 我当前的实施方案只有1{}，我希望这不会产生任何副作用。
5. 我需要在看门狗复位期间执行一些文件操作、因此使用了单独的线程而不是 WDT ISR。 在我的实现中、我已将此设置为具有最大优先级、因为我需要无论其他线程状态如何都执行文件操作。
6. 所以我不需要在我的实现中使用 Power_disablePolicy()和 Power_enablePolicy()？
7. 好的
8. 好的
9. 好的。  

此致

Zac

您好、Kobi、

查询是否有任何更新？

此致、

Zac

看门狗不需要分离的线程(您可以在中断处理程序中工作或使用任何线程上下文重置看门狗)。

2.我不理解您对调用看门狗的上下文的关注。 唯一与线程相关的问题是看门狗被复位的上下文。 无论如何、您可以在主代码中为看门狗创建一个较低的线程(创建线程时、对您设置的优先级没有限制)。

4、这意味着您基本上决定在 X 秒后复位(看门狗超时)、但您的应用程序将继续运行 X 秒、直到执行实际复位。 这是不必要的延迟、可以更好地处理。 如果 while (1)将在高优先级上下文中发生、则系统将无响应、直到发生复位(即 X 秒)。  

5.这应该起作用。

6.如果要使用低功耗，则需要启用电源策略(在 init 时)。 您不需要像示例中那样在禁用和启用之间切换。  

BR、

Kobi

感谢 Kobi 的反馈。 我们的 WDT 例程在少数模块中未按预期工作、因此我们希望确保看门狗的使用正确。

看门狗的实现方式是、如果 MQTT 连接持续4小时以上无法建立、WDT 会触发复位。 但是、即使在连接失败2天后、我们的模块(70个生产单元中的3个)也很少会复位或恢复。 无法从这些模块获取日志、除非 WDT 失败、否则不会出现这种行为、这似乎不是这样。 这些模块仅在我们执行硬复位后才恢复联机。 我们在开发过程中多次测试了 WDT 复位例程、它始终有效。
WDT 是否会完全复位 MCU 和 NWP？ 我们最近在调试期间注意到的一点是、一旦 NWP 在少数 WDT 复位后未恢复。 也就是说、复位例程工作正常、MCU 重新启动且 WLAN 已连接、但无法成功连接套接字。 即使存在互联网连接、SNTP 调用失败、OTA 调用失败、MQTT 连接失败。 当我们使用复位按钮进行硬复位时、它最终起作用。 虽然这种情况只发生一次，但这可能是我上述问题的一个原因。 可能发生了 WDT 复位、但 NWP 可能尚未完全恢复、这将导致连接出现数天故障。 您认为这可能发生、还是我们应该去别处看看？ 感谢你的帮助。

此致、
Zac

您好、Kobi、

此外，如果 NWP 由于驱动程序中止或某些内存问题而失败，WDT 复位能否恢复它？ 或者，在任何驱动程序故障期间，我们是否应该显式调用 sl_Stop(300)或使用 Platform_Reset()手动复位？

此致、

Zac

您好 Zac、

理论上、WDT 应该用于您之前没有预料到的问题。 如果您正在监控特定错误、则可以触发 Platform_reset。

最好在 MCU 从 WDT 复位唤醒时复位 NWP (SL_Stop/SL_Start)。 我不确定 WDT 是否复位 NWP。

BR、

Kobi

您好、Kobi、

是的、在从 WDT 重新启动恢复后、在 CC3220和 CC3235上执行 ROM 引导加载程序重新启动 NWP (以及 MAC 和基带)。 此恢复问题仅在 CC3200中出现。 请参阅 TRM 第10.4.1章。

1月

谢谢 Jan！

BR、

Kobi

感谢 Kobi 和 Jan、

我也读出 CC3220可能不需要与 CC3200类似的显式 NWP 复位。 那么、我们的模块出现故障的原因可能是什么？ 我们看到越来越多的模块在生产中出现故障、这已成为目前的主要问题。 可能是噪声、存储器溢出甚至一些应用程序错误、但 WDT 应该有助于恢复 RITE？  

如果有人能优先考虑并尽快帮助我们、我们将不胜感激。 我们已经开始使用该产品、不易召回。 我们希望您能理解。

此致、

Zac

您好 Zac、

我不知道任何其他可能导致 WDT 卡滞的潜在问题、但我之前的回答中描述了两个原因。

可能还有一个额外的原因。 如果我没有错、WDT 的时钟将在省电模式中选通。 可能是节电方面的问题、可能是错误的。 如果您无法在办公桌上模拟问题、很难为您提供合理的建议。 但我同意 Kobi 的说法。  WDT 应用作最后的防御边界以及您应该在代码中解决的所有预期问题。

老实说、我并不完全理解您围绕 WDT 的代码设计。 该设计听起来非常复杂、很容易出现潜在的实施问题。 但也许 这只是我对理解的问题。

1月

您好、Jan、

您能否提供有关 您提到的第二个原因(即 WDT 使用主时钟且该时钟由 PRCM 外设选通)的更多信息或方案？

此外、CC3220中的任何节电模式是否会干扰 WDT？ 请提供更多详细信息吗？

谢谢

Zac

您好、Kobi、

您是否认为卡住的 sl_Stop 函数可能会干扰 WDT 计时器？

我正在读取以下线程并发现它与 之类似- https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/759892?tisearch=e2e-quicksearch&keymatch=CC3220:%20WatchDog%20did%20not%20trigger

在我们的代码中、如果有任何驱动程序中止、我们将调用 sl_Stop、并且有时诸如 ADC 之类的一些外设仍会打开。  

在驱动程序中止过程中执行的最合适的步骤是什么？ 我们有一些要编写的文件、因此我希望 sl_Stop 和 sl_Start 是必要的 rite？  

对于任何特定错误、我们应该在 Platform_reset 之前调用 sl_Stop (零超时)吗？

非常感谢您的快速支持。

此致

Zac

您好 Zac、

第二点是通过 driverlib PRCM API 禁用 WDT 外设的时钟。 它通常与调用诸如 PRCMPeripheralClkDisable (PRCM_WDT、PRCM_RUN_MODE_CLK)之类的 API 有关。 我不希望您无意中这样做。 此外、CC32xx 器件上的 WDT 具有一项功能、可在调试期间达到断点时停止 WDT。 这也不应该是您的问题。

CC32xx 器件的电源管理驱动程序在省电模式期间对 WDT 进行门控、因为它很简单、而且对于正常功能而言是强制性的。 您可以自己查看\source\ti\drivers\power\PowerCC32XX.c 内的代码、并了解此驱动程序在内部的工作方式。 重要说明是包含 MAP_PRCMPeripheralClkDisable ()的行、并使用 PRCM_WDT 元素结构 PowerCC32XX_MODULE。 从理论上讲、该驱动器内部可能存在一些问题、但我认为这种情况不太可能发生。 CC32xx SDK 内部有一些代码我不使用、因为我对它不信任、但该电源管理代码不是其中之一。

如果我需要猜测、我会怀疑您的代码设计和使用 WDT。 为什么？ 这很简单。 我无法完全理解您代码的设计。 我为有线/无线以太网器件编写了许多固件、其中功能安全是设计的关键部分。 您的功能安全设计对我来说太复杂了。 我的方面建议很少：

• 尝试将代码重新设计为 WDT 作为最后的防御边界、而不是恢复机制的组成部分、以防出现您可以预期并以不同方式解决的问题
• 请尝试让您的项目之外的其他人(例如贵公司的不同部门)独立检查您的代码
• 在分解所有模块的过程中查看您的代码、花点时间尝试模拟您的问题

BTW... 关于复位前应调用 sl_Stop()的位置以及不应调用的位置的主题非常复杂，会产生许多后果。 我将把答案留给 Kobi、因为在这个答案中、我已经写了太多的行。

1月

谢谢 Jan 我们将 WDT 用作最后的防御边界、由于有多个线程、我想它已经变得有点复杂。 我们还删除了所有全局变量(如前所述)、并为 kicker 线程使用了 mqueue。 我们有6个线程需要保护、因此每个线程都需要为 kicker 线程提供心跳信号、从而最终清除 WDT 中断(如果所有线程都按定义的间隔报告)。 我们对 kicker 线程进行连接检查(即几个小时内未报告互联网连接)的原因是、我们遇到了 NWP 因未知原因而失败的情况、无法找到它们并恢复此类故障。

既然您提到了 WDT 的调试停止、您是否认为 WDT 在生产模块中启用时可能会失败(尽管预计不会出现断点)？

WDT 是最后的防御措施、即使存在任何逻辑、存储器、LPDS 甚至驱动器故障、WDT 也能可靠工作。 但是、在许多情况下 WDT 出现故障、这确实令人震惊。 WDT 在产生其他线程之前在主线程中启动、在某些情况下(驱动程序中止、sl_Stop、LPDS 等、理想情况下不应产生任何干扰)、WDT 看起来会被暂停。

我们现在有7个模块(7个客户)、它们报告了随机崩溃、尽管有 WDT 逻辑已就位、这是一个主要问题。 我们非常希望能够优先确定和解决与 WDT 有关的任何问题、从而避免进一步的担忧。 我知道、如果不在调试器中复制相同的内容、很难找到原因、但如果有人可以重新检查 WDT 库和实现、可能会有所帮助。

感谢所有支持和快速帮助。

此致、

Zac

您好 Zac、

在我的应用中、我使用从 driverlib 配置的 WDT。 我从未见过任何 CC32xx WDT 问题。 我的应用非常复杂、有18个任务。

在我之前的帖子中、我讨论了 CC32xx WDT 的失速功能(请参阅 TRM 第10.3.6章寄存器 WDTTEST 和位失速)。 但我认为这不应该与你的问题有关。

WDT 是一种非常简单的外设、如果启用了主时钟并且您正确启动 WDT、它很可能会失败。

BTW... 您在什么地方启动 WDT？ 这是您的"主管"任务还是 WDT 中的 ISR？

1月

您好、Jan、

我们正在从监控器任务中清除看门狗、并且我们在 ISR 中不执行任何操作。

WDT 打开是我们在应用中执行的第一项任务、计时器初始化不太可能失败。 唯一的变化是、重新加载时间在 WDT 初始化后很快动态更改为5秒。 这也已经过测试。

Platform_reset 是否与 WDT 有任何关联？ 在调用 Platform_reset 之前是否应停止 WDT？

我们真的很坚持这一点。

此致、

Zac

您好 Zac、

我们正在从监控器任务中清除看门狗、并且我们在 ISR 中不执行任何操作。

好的、这是正确的方法。 因为清除 ISR 中的 WDT 可能会带来潜在风险。

Platform_reset 是否与 WDT 有任何关联？ 在调用 Platform_reset 之前是否应停止 WDT？

我不知道 REST 和 WDT 之间有什么相关性。 platform_reset ()函数在内部调用 PRCMHibernateCycleTrigger ()，此函数触发较短的休眠周期。 这是因为对于完整的 SoC 复位、也必须重新启动 MAC 和基带(不仅是应用 MCU 和 NWP)。 CC32xx WDT 硬件一旦启动就无法停止。 唯一的方法是通过 PRCM API 切断主时钟。

是的、我知道您有问题。 但我不确定其他人如何能够帮助您。 如果您无法在办公桌上模拟问题、那么更不现实的是、一些没有代码和硬件的外国客户将能够找出您的问题所在。

1月

谢谢 Jan

我一直在尝试跟踪模块崩溃时的场景、看起来这些模块在 OTA 成功后出现了问题。 这些器件在 OTA 后确实恢复联机、但在一段时间后出现故障(尤其是在 WLAN 断开一段时间或互联网不可用时)。 此外、在我们执行手动/硬复位后、这些模块工作正常。 这是否意味着 Planform_reset 以及 OTA 中的 sl_Stop 未完全复位 SoC？ 还是干扰了 WDT？

此致、

Zac

您好 Zac、

我没有这种行为的解释。 尤其是在使用 TI OTA 代码且 OTA 过程已成功完成的情况下。 WDT 的正确功能是 OTA 更新过程不可或缺的一部分、但我不确定这会如何影响您的情况。 请等待 TI 方面的回答。 也许他们会有任何想法。

1月

执行 TI OTA 时、MCU 复位后、引导加载程序会触发 WDT 以保护新映像的验证。 此行为基于"Platform_CommitWdtConfig"中的代码-如果引导加载程序在 器件以 OTA 模式加电(等待提交)时找到具有有效配置(超时)的"/sys/mcubootinfo.bin 系统文件、则会启动看门狗。

在我们的示例中(例如 cloud_ota.c)，一旦您决定提交新 映像(选中 OtaCheckAndDoCommit())，"Platform_CommitWdtStop" 将重置 WDT。

此行为可能与您的使用冲突。

BR、

Kobi

您好、Kobi、

OTA 看门狗调用- Platform_CommitWdtStop 会禁用应用程序中启动的 WDT 吗？ 我们假设这两个都使用不同的计时器。  

我找不到任何说明此类问题的文件。 请提供更多详细信息吗？ 如果存在冲突、那么我们应该如何将应用 WDT 与 OTA 看门狗一起使用？

此致、

Zac

您好 Zac、

我认为、随着您对 OTA 的发现以及 Kobi 的最后评论、我们能够继续前进。 我认为这可能是你提出问题的理由。 由于 OTA 使用的 WDT 与您使用的 WDT 相同(CC32xx 上没有多个 WDT、这些 WDT 是设计用于应用 MCU 的)。

函数 Platform_CommitWdtStop()在内部调用 TI-Driver API PowerCC32XX_RESET (PowerCC32XX_Periph_WDT)，该 API 在内部调用 MAP_PRCMPeripheralReset (PRCM_WDT)。

来自 TRM：

我认为您的下一步应该是在 OTA 更新后立即测试您的 WDT 系统。 只是为了确保您处于正确的方向。

1月

谢谢 Jan、  

我想这就是 WDT 停止的原因。 我现在没有开发板、我将尽早对此进行测试。

同时、该问题的解决方案是什么？ 我认为两个看门狗都是必要的、必须应用某种逻辑。

此致

Zac

您好 Zac、

我不太确定。 可能是器件重启、或者只是重新配置和启动 WDT。 您可以等待 Kobi 的回答、也可以自行找到最佳解决方案。 好的想法是、这可以很容易地进行仿真。

1月

您好、Jan、

我刚刚使用 OTA 测试了我的 WDT、并确认它确实是 PowerCC32XX_RESET (PowerCC32XX_Periph_WDT)调用阻止了应用 WDT 并最终导致系统故障。 我认为、任何使用 WDT 和 OTA 的人都会遇到相同的问题、这需要快速解决。

您好、Kobi、

请您优先考虑这一点并为我们提供最佳解决方案吗？ 我还会请求您在 OTA 示例以及 WDT 示例中添加警告、指出 WDT 是共享的、会干扰应用程序。

此致、

Zac

您可以在提交完成后启动 WDT、也可以在提交完成后(再次)重置 MCU (以便在运行模式下唤醒)。

在这两种情况下都将使用 WDT 设置。  

BR、

Kobi

您好、Kobi、

请提供有关所需更改的更多详细信息。 代码片段会非常有用。

启动两个 WDT 计时器时会发生什么情况？ 应用 WDT 设置为每5秒运行一次、其中 OTA WDT 为50秒。

如果您能进一步分析、并帮助我们添加一个简洁的解决方案、请不胜感激。

此致、

Zac

尊敬的 Kobi 和 TI 团队：

如果您能尽早提供解决方案、请不胜感激。

此致、

Zac

您好 Zac、

我想 Kobi 已经回答了你的问题。 提交后、您可以重新启动 MCU 或再次启动 WDT。 选择由你决定。

正如我之前所说的。 只有一个 WDT。 OTA 代码使用的 WDT 硬件与您使用的软件相同。

1月

您好、Jan、

应用程序将 WDT 间隔设置为5秒、我相信 OTA WDT 将因此受到影响。 在 OTA 线程之后启动应用 WDT 也有一些缺点。 我会要求 TI 团队进行仔细分析、并提供稳定的解决方案、而不是稍后可能会中断系统的变通办法。

此致、

Zac

您好 Zac、

我不确定您的期望是什么。 我已经介绍了 WDT 机制和 OTA 支持、现在由您决定如何在应用中使用 WDT。

除了前面的建议之外、您还可以执行以下操作之一：

1.禁用 OTA WDT (方法是不在 Platform_CommitWdtConfig()中写入"/sys/mcubootinfo.bin -确保文件尚未存在于文件系统中)，但您会面临损坏映像无法运行的风险(因此不会触发 WDT)。

2.更改 OTA WDT 默认超时时间(由 OTA 示例设置的50秒，请参阅 OtaInit()中的)

BR、

Kobi

您好、Kobi、

我们希望您了解这些问题的重要性、以及它们对产品品牌和市场占有率的影响。 如果您知道任何产品可能在一天内发生故障、则根本不建议禁用 OTA WDT。 我们还没有看到任何来自您的注释、说明整个 OTA 如何与 WDT 回滚一起工作。 用户手册似乎没有对 OTA 过程的 WDT 部分进行说明。 如果我们错过了什么、请告知我们。

我们还不了解在 WDT 启动或打开两次(首先是 OTA 启动文件、然后是应用程序)时系统的行为(长期)。 我们根据 TI 的价值和质量来选择 TI、我们真的很担心到目前为止遇到的问题数量(其中大多数问题在本论坛中报告)。 在启动过程中、大多数实现都源自 TI 的示例(尤其是 OTA 和配置)、如果您能使示例更完整、更稳定并记录在案、我们将不胜感激。 我们确实接受这样一个事实：我们在使用之前未能探索一切，但我们的选择是有限的。

尽管我们已经报告了 WDT 故障、但没有人真正指出 OTA WDT 的使用情况、并且在任何测试或调试中都无法发现它。 我们假设可能还有其他公司甚至没有发现这种情况。  到我们发现问题时、我们的客户中有超过10%受到影响。   

我们仍然认为，最好的解决办法来自了解整个系统并因此要求采取更好办法的制造商。 我希望您能了解情况并帮助我们。

此致、

Zac

您好 Zac、

我理解这一点至关重要、并且理解您的沮丧情绪、但我只能解释您的机制和选择。

我们一直在努力改进示例和文档。

我同意不建议禁用 OTA WDT。

我确实建议了几个您可以使用的替代方案。 我不知道您还在寻找什么、

当触发新映像(即在 OTA 下载成功之后)时，将使用 OTA WDT。 如果一切正常、应提交更新、然后可以重置 OTA WDT 并使用应用程序 WDT (或者可以重置 MCU、OTA WDT 不会再次触发)。

如果您发现映像有问题、则可以触发还原(或仅重置 MCU)。 您还可以等待 WDT 过期并重置 MCU。 在所有这些情况下、复位后将触发之前的映像(由于失效防护机制)。

BR、

Kobi

OTA WDT 在应用程序启动之前由引导代码启动。

我不确定如果应用程序更改超时会发生什么情况。 我认为应用程序超时不会影响原始 OTA 版本(因为超时值仅在 WDT 启动时或超时时时时加载)、但在这种配置过程中可能会出现错误。 如果器件处于待提交状态、请尝试避免此初始化。 您可以使用以下命令轮询状态：

int32_t isPendingCommit；
int32_t isPendingCommit _len；
Int32_t 状态；

状态= Ota_get (EXTLIB_OTA_GET_OPT_IS_Pending_commit、isPendingCommit_len、(uint8_t *)&isPendingCommit)；

Platform_Reset -应该正常。 无需关闭其他外设。 要处于安全侧、请在 MCU 复位之前调用 sl_Stop。

BR、

Kobi

您好、Kobi、

很抱歉、我删除了一些帖子、以避免混淆。 在对 OTA WDT 进行更改之前、我们需要进一步澄清。 如果我们的任何陈述有误、请更正我们的错误。

1) 1)固件在 OTA 超时过期时如何回滚？ 我们的理解是、在 OTA 下载后的引导过程中、如果发生 OTA WDT 超时(第二次过期)、MCU 将被重置(WDT MCU 重置)、并且由于未完成映像提交、下次引导时系统将回滚到旧映像。 isPendingCommit 下次是否会为 false、OTA WDT 计时器是否会再次启动？ 如果您能解释它的工作原理、那将非常有帮助。

2)使用 Ota_get (EXTLIB_OTA_GET_OPT_IS_Pending_commit、&isPendingCommit_len、(uint8_t *)&isPendingCommit)查询 isPendingCommit、然后启动应用 WDT 似乎没有问题。 但是、何时应启动 OTA WDT (写入 mcubootinfo.bin)。 它当前位于 OTA_Init()和 OTA_Init()内部，在每次启动时以一定的周期性间隔(每天一次)运行。 这是否会导致 OTA WDT 始终启动、即使没有 OTA 更新也是如此？ 这是否会再次干扰应用 WDT？

3) 3)我们有几个实例、其中 OtaImageTestingAndReset 内的 sl_Stop 卡住、并且由于 ADC 引脚未闭合而无法返回。 我怀疑在调用 sl_Stop 时是否会发生类似的问题。 此外、在 OTA 过程中会禁用应用 WDT (根据建议的方法)、并且我们执行具有100%可靠性的完整 SoC 复位至关重要。 因此、关闭外设、调用 sl_Stop、然后调用 Platform_Reset 似乎可以安全地完成重新启动。 如果不需要、您可能会不同意。

此致、

Zac

感谢 Kobi、

关于第2点) 是否需要在 OTA_INIT 期间写入 mcubootinfo？ 映像下载完成后、我们可以执行此操作吗？ 它是否会产生其他副作用？

此致

Zac  

您可以在调用 sl_Stop 和 MCU 复位(映像下载后)之前随时执行该操作。

BR、

Kobi

您好、Kobi、

 在成功下载后和 sl_Stop 之前写入 mcubootinfo 在我们的开发环境中似乎可以正常工作。 不过、我可能还没有测试过所有案例。

 在示例代码中的 OTA_INIT 内部执行 mcubootinfo 写入是否有任何具体原因？ OTA 检查在大多数情况下会频繁执行、如果不进行更改、则会导致闪存磨损。  

此致、

Zac

实施这一措施有具体的原因。 这只是一个示例。

 mcubootinfo 只是文件系统上的另一个文件。 您可以随时编写它。 只有引导加载程序在 MCU 复位时才会引用该选项。

BR、

Kobi