工具/软件：
您好：
我需要看门狗管理方面的建议。
在微控制器的两个 CPU 上、我为看门狗配置了一个导致 PIE 中断 (WAKE) 的看门狗
在关联的 ISR 中：
-我在 CPU 的闪存中写一些东西
-我将看门狗的模式切换为 RESET_MODE
-由于 driverlib 函数 sysctl_resetDevice (),我要求一个看门狗复位。 此函数实际上会在看门狗寄存器中放置一些错误的内容、这会导致看门狗事件（这就是我将此事件设置为“复位“的原因）
当 CPU1 中有阻塞任务时、一切都正常：两个内核都会复位。
当 CPU2 中有阻塞任务时、我预计：
- CPU2 重置并等待 IPC_SYNC 继续其程序
- CPU1 看门狗到达（因为 CPU1 将许多数据传输到 CPU 并等待确认）并请求 CPU1 复位
- CPU1 和 CPU2 复位（CPU2 第二次复位）
-整个程序第一次运行
但有时、在仿真模式下、当 CPU2 上的看门狗出现时、CPU1 会跳入此函数：
我在参考手册中看到、CPU2 看门狗复位导致 NMI。 所以,我有很多问题:
1) NMI 处理程序在 driverlib 文件中定义。 如果我必须管理 NMI、我该怎么做、因为我“无法“修改 driverlib 文件？
2) 我注意到每次引起 CPU2 看门狗事件时、我都没有进入此处理程序。 怎么会这样? （在我的应用程序中，仅当之前出现 CPU1 看门狗时才进入此处理程序）
3) 我在独立模式下运行我的项目,程序不会进入无限循环。 一切似乎都还可以。 NMI 是否可能是由于仅出现在仿真模式中的其他原因（时钟故障，错误...）造成的
4) 我在参考手册中读到、当信号 WDINT 处于活动状态 (512 SYSCLK) 时、不得更改看门狗模式。 但我确实改变了它。 我应该先等待才能做到这一点吗? 使看门狗事件引起复位是否真的有用？
5) 最后,在我的应用程序中,如果看门狗出现,阻止 CPU2 程序是否更安全? （由于应用程序的原因，这将导致 CPU1 上出现看门狗）
感谢您的建议。 我努力做到总的和明确的。
Vincent。
