我正在运行两个任务，一个任务是更新看门狗，另一个是执行应用程序逻辑。当我在应用程序逻辑中进入do - while循环时，应用程序崩溃，当我使循环条件为假时，它将只执行一次;应用程序不会崩溃。我假设我崩溃是因为看门狗，但我不能100%确定。为了防止应用程序在循环中崩溃，我调用了wdg_reload(0xFE);无论如何，这都没有任何影响，并导致应用程序崩溃。然后我试着冻结看门狗，并在循环之后恢复它，这也没有效果，而且崩溃了。虽然当我删除do - while循环时，应用程序运行得很好，但是在那里使用循环逻辑会工作得更好。我还试图禁用所有看门狗，我看到的是，应用程序从来没有崩溃，但它似乎不像我预期的那样执行，尽管这可能是其他因素。
这是看门狗崩溃的症状吗?为什么当我更新或冻结它时，它仍处于监视状态?
设备:
嗨mark.bloechl,
看门狗应该更新和冻结，我认为是其他原因造成的，或者它是看门狗和卡在其他地方，你应该确保你的应用程序崩溃，因为看门狗超时。所以你必须确保你的应用因为看门狗而停滞，当应用“崩溃”时，设备应该堆叠在NMI_Handler中，你看到你的设备碰到那个处理程序了吗?如果你有，你可以从PC上检查，检查看门狗被触发的确切位置。
由于MT_dialog
我已经测试了代码，看看它是否会崩溃在NMI_Handler和它确实。当我添加循环功能时，它在NMI_Handler中中断，当我删除循环功能时，它在NHI_Handler中从未中断。
我相信这个测试证明了有一个看门狗相关的崩溃，它是从循环功能被特别地调用。
嗨mark.bloechl,
自敝中断发生在你把循环的循环还有东西在摊位的代码超过2.6秒(因为你是更新的监督以0 xfe值),或者循环影响你的代码和敝中断发生在其他点(按照方法我mentiond并检查电脑之前敝中断发生)。我想，即使当你更新看门狗时，设备也会停止，如果指令位于循环中，那么循环只执行一次。
你可以做一个关于看门狗和NMI的小测试来熟悉一下，使用一下(1);并将其放在来自SDK的项目示例中的某个地方(例如，当你编写一个特征时)。当你编写特定的特征时，代码应该到达NMI。然后替换while(1);使用while(1) {wdg_reload(value)}，不应该强制执行NMI，但它会在那个点上停止你的代码(更新看门狗的值)。
由于MT_dialog