工具/软件：
您好：
我们在 Sitara 上使用的是 DWWD。
我们的应用非常简单：我们有一个任务和一个看门狗。 此任务会在短于看门狗周期的时间内清除看门狗。 因此、触发不会发生。
在调试构建时停用看门狗、在发行构建时激活看门狗。 如果我们要调试版本构建、由于看门狗在某些情况下会触发、因此我们会遇到一些问题：
如果器件上已经存在 release-build 并且通过 CCS 加载了 release-build：watchdog 会在 watchdog_clear () 之后立即触发
如果器件上已经有调试构建、并且首先通过 CCS 加载了版本编译：工作。
如果随后再次加载发行版：看门狗立即触发。
因此、如果看门狗配置一次、它会直接触发、我不知道为什么。
我们还编写了自己的看门狗驱动程序、该驱动程序利用了看门狗功能、但我在示例和 TRM 中有所介绍。 我所做的与示例相反的唯一事情是清楚的、因为 TRM 说：
“RTI_INTR_WWD 中断处理程序需要清除看门狗违例状态标志、然后通过在看门狗密钥 RTI_WDKEY 寄存器中写入正确的序列来对看门狗进行维护“
但这些例子却相反。 尽管如此、问题依然存在。
通常、我们可以说这是用于我们的看门狗的代码： 
BFWATCHDOG_OPEN 与 WATCHDOG_OPEN 相同、不同之处在于它不采用数组索引、而是配置本身。
我们还将其用作 Fiq-interrupt、因为我们注意到 HwiP_disable 也会阻止看门狗中断、但这不应该发生、并且 NMI 在 am243x 上也不可用：
AM243X-AM243X：RTI_DWWD 没有不可屏蔽中断 MCU-PLUS-SDK？ -基于 Arm 的微控制器论坛 — 基于 Arm 的微控制器 — TI E2E 支持论坛
我们使用看门狗实例 8、即 mcu0_0 上的 TISCI_DEV_RTI8/WATCHDOG_INST_ID_8。 另一个是对应于 mcu0_1 的 9。
因此、如果我们的器件上已经有版本构建、下面我们来看看： 
WDSTUS 看起来不错。
现在、在 Watchdog_clear 返回时：
WDSSTATUS 以某种方式被设置？
CCS 不使用 v1 文件、但 V0、这就是该行与左侧代码不匹配的原因。
但我们始终会遇到这种情况、因此无法调试已包含发布固件的电路板。 那么、一个已经初始化看门狗一次的固件。
此外、我们的看门狗周期设置为 16 秒！ 所以这不像我在断点时间过长或过短。 它会在启动后创建看门狗后立即发生。
是否还有其他没有记录的内容、或者我刚刚通读过、需要做些什么才能完成此工作？
在某些情况下、真正需要这样才能调试我们的发布固件。 这是不可能的。
此致
Felix
