ARM调试(3):在keil中不复位调试MCU

当单片机程序运行突然异常后，若是没有在仿真模式下，只能通过硬件的表面现象来分析，由于反馈到的信息做得并不是很全面，但是插上仿真器，开启debug程序就会重启，刚刚复现的bug将不复存在，而开启debug程序就会重启主要是插上仿真器以后，调试器在启动时会发出硬件重置信号，应用程序当前的状态都会丢失，包括内存变量、状态等等，对于一些长时间的偶发故障调试更不太友好。

对此我们其实有种迫切的需要：一旦程序出了问题，我只需要插上仿真器，目标硬件不会复位，而是与我当前所调试的程序同步，类似于仿真程序的时候的“全速运行”，然而通过添加断点，便可查看程序具体的运行状态，内存等等信息。

大家调试的需求也是一种用户需求，相应工具的开发厂家会根据相应的需求进行开发，所以该功能在大部分主流的开发工具中都已具备，下面我们就用Jlink来验证一下这个功能。

首先编译好工程，把程序完整的烧录到mcu，必须要保证MCU中正在运行的程序与所要仿真的工程程序完全一致，这样调试器通过调试接口获取的程序运行位置信息才能与工程代码中的位置一一对应。

新建一个.ini后缀的文件，本文新建文件为debug_itm.ini并写入文件内容，如下：

在keil的配置页面，去掉启动时加载应用程序选项的勾号，并加入debug_itm.ini文件，主要用于加载已经编译生成的.axf文件到Keil中，从而进行调试，如下：

解释一下.axf文件：

axf全称为:ARM Executable File，当你编译的时候除了生成hex烧录文件外，其实还生成了很多其他文件，这些文件我们统称之为中间文件。其中就有.axf文件，该文件包含bin代码和大量的调试信息，这些调试信息可以被调试器使用，从而定位到我们的C代码。

注意：有些人喜欢在工程里面添加清除中间文件的命令文件，千万不要将.axf文件清除掉。

在调试器Setting选项中，去掉"Reset after Connect"，这样调试器链接以后不会进行复位动作，从而保护现场。如下：

接下来Update Target Before Debugging选择需要去掉，直接调试运行目标不需要勾选，也就不会更新Flash。

这样的话，在调试的时候，芯片就不会复位了，当出现偶发性问题，接上jlink，就可以debug不复位调试了。

注意：

jlink的20pin引脚中，有一个复位引脚，当我们不给jlink供电，直接接到mcu上的时候，jlink复位引脚不上电默认是低电平，会将芯片reset引脚拉低导致芯片复位，解决办法有两种，1：不接jlink的reset引脚；2：先将jlink插到电脑上，给jlink供电，然后再将jlink插到mcu接口上；

首先我们要区分开下载和调试，这是两个不同的功能。

下载是通过下载算法来实现的，下载算法实际就是一段程序，在当你点了下载按钮，下载器会将下载算法下载到mcu的RAM里面，然后运行这个程序，下载器再将用户的程序传到mcu中，ram里的这段程序会接收这些然后写到相应的flash地址中。

而调试和下载原理不同，有很多人一直对调试有一个误解，觉得仿真程序是把运行程序通过加工调试信息，然后全部下载到MCU，在进行仿真调试。这种想法在是不太正确的，其实调试器只需要知道程序运行到哪里，并且查看内部信息、控制程序的运行等，便可以反推定位程序当前所运行的位置和状态，这也是本文开头的前提条件，烧录到Flash上的固件与你即将要仿真的代码工程要保持同步，否则调试的时候就会乱，仿真就是上位机控制调试器与MCU内部仿真模块进行通信，在从而完成调试信息的交互和控制。

之前我写过一篇文章，介绍如何使用ARM的ITM来实现printf和scanf，但是一致有一个问题，那就是在启用ITM的时候，mcu会复位，但是现在有了完美的解决方案。关于ITM的相关知识，请参考我的ARM调试(2):在keil利用指令跟踪宏单元(ITM)重定向printf，并完成scanf实现数据双向交互。

因为本次实验使用JLINK实现ITM，因此若实现ITM的printf不复位，那么需要修改debug_itm.ini文件，如下：

关于为什么这样修改，请参考我的那篇文章。

其他的设置和上一篇的文章设置ITM方法一致，现在我们在程序里面测试，让一个全局变量从0不断的累计，然后用printf打印出来，先让程序运行，然后再启动debug，发现变量不是从0开始，证明程序并没有重启，如下图：

【图我在整理的时候忘记截了】