前几日，中矿龙科的李工向我反映了一个有意思的问题：

在使用TKScope仿真器(型号AK100pro)调试STM32时，出现了一个非常奇怪的现像。在Keil环境中的源代码设置了一个断点后，全速运行，STM32能正确地运行到断点处并停止，Keil也切换到停止状态。之后不做任何操作，过了一小会儿后，STM32居然自己“全速”跑了起来。

最开始，我怀疑是断点没有设置好。但是既然STM32能够在断点处停止，则可以确定Keil和驱动是没有问题的。从现像来看，芯片已经脱离了仿真器的控制，而只有芯片发生复位操作才能导致这种结果。

基于以前的技术支持经验，初步将问题点锁定到了看门狗。看门狗在调试过程通常不受控，突然产生内部复位，造成困扰。问了李工，果然是程序中有开启了看门狗。之后建议李工关闭看门狗再调试，问题消失。

为什么看门狗会有影响？

在MCU中，看门狗已经成了一种标准外设。这种外设的作用是在程序运行发生异常后的一段时间内产生复位信号，使得程序能够完全重新运行，回归到一个正常状态。其工作原理如下图所示。

正常情况下，各个任务需要不断地“喂狗”。每一次“喂狗”操作会清零看门狗内部的定时器。一旦无法喂狗或者喂狗不及时，内部定时器将计数至溢出，产生复位信号。

在某一些场合，工程师们可能选用带看门狗的外部复位芯片。这类芯片的复位输出直接连接至MCU的复位引脚。这样就会造成两种不同的复位效果：

   
• 只复位内核：通常为内部看门狗复位。复位时不影响调试模块，所以复位后仿真器仍然能正常连接；

   
• 同时复位内核及调试模块：比如使用外部复位芯片。仿真器将失去与芯片的调试模块连接。

无论是哪种复位效果，频繁的复位将使你无法进行任何调试操作。

李工所遇到的问题的真正原因是：在使用AK100Pro仿真器调试时，全速运行状态下，程序在不断喂狗。但是一旦遇到断点并停止，这个喂狗操作也就停止，此时看门狗还在继续运行，之后产生复位。

为什么内核停止时看门狗还在运行？

很多人以为用仿真器调试时程序的运行效果跟脱离时跑是一样的。其实不然！李工的这种情况，就是一个例子。STM32在遇到断点停止后，内部看门狗实际上还在运行，甚至于其它部分外设也仍然在运行。当然也有一些厂商的芯片被设计成内核停止时，相关外设全部停止。不同的芯片，采用的策略各有不同。至于为什么是这样，要问芯片设计者，我们是不得而知的。

如何解决这个问题？

首先，要看面对的是外部看门狗还是内部看门狗。

如果是外部看门狗，你唯一的选择是断开。例如下图中SP706S，复位时间为1.6s，在你执行单步、设置断点、查看变量等操作时，很容易超过1.6s。正因如此，在我们公司的SmartARM3250开发板上，这颗复位芯片默认没有焊上。

如果是内部看门狗，要看具体的芯片特性。如果内核停止时，看门狗继续运行，则在程序中不能打开看门狗。

有一些芯片允许配置看门狗在内核停止时自动停止。对于这类芯片，TKScope仿真器提供了一种很灵活的方法允许我们进行该配置。同样，以李工的这个问题为例子。

STM32内部有一个名为DBGMCU_CR的寄存器(地址0xE0042004)，其部分配置位意义如下：

注意其中的DBG_WWDG_STOP和DBG_IWDG_STOP位。这两个位允许配置内核停止时停止看门狗时钟，达到停止看门狗的目的。

那么李工可以这样做：在调试前，将这两个配置位写1。程序中不必关闭看门狗，也就不必改源码。这可以很容易的通过TKScope仿真器的【初始化宏】配置界面实现。

【初始化宏】允许TKScope仿真器在调试过程中的不同时期，执行不同类型的操作，常见的操作有设置复位矢量、读写寄存器、Memory等，非常灵活。

给工程师的建议

如果你在使用TKScope仿真器调试过程中发现突然无法调试，并且每次都能重现，非常有规律；那么很可能就是看门狗引起的。此时，请参考上面的方法解决问题，如果问题无法解决，请联系TKScope仿真器的技术支持。

附注

我在以往的技术支持过程中遇到不少的“奇怪”的问题。其中，绝大多数都是与具体使用的芯片、所调试的程序有关。这种问题使得工程师们非常困扰，不知道是硬件问题，还是程序问题，还是仿真器问题，有时严重影响开发进度。为了减少这些问题给工程师们带来的困扰，后续我会不定期的将平时技术支持过程中比较常见的问题和解决方法总结下来，以这种案例的形式，写成连载文章《与TKScope仿真器同行》，发表在我的博客上。期待你我一起与TKScope仿真器同行。

本文转载自我的仿真器专业博客：与TKScope仿真器同行(1) – 看门狗会让你无法调试。如果你觉得该文章有用，欢迎转载。