文章目录
- 前言
- 步骤1
- 步骤2
- 步骤3
- 步骤4
- 步骤5
前言
经常有朋友在开发中遇到这样的窘境,当单片机程序运行异常以后,由于调试信息做得并不是很全面,导致相应的问题场景非常难分析。当时的你肯定会叹息道:“要是我一直插着仿真器就好了,这个bug还不是分分钟的事~”,每个人都想有颗“后悔药”可吃,然而遇到这种场景也并非绝路。主要是因为大部分朋友插上仿真器以后,调试器在启动时会发出硬件重置信号,应用程序当前的状态都会丢失,包括内存变量、状态等等,对于一些长时间的偶发故障调试更不太友好。此时此刻有一种调试需求是朋友们非常想要的:一旦程序出了问题,我只需要插上仿真器,目标硬件不会复位,而是与我当前所调试的程序同步,类似于仿真程序的时候的“全速运行”,然而通过添加断点,便可查看程序具体的运行状态,内存等等信息,让bug闻风丧胆。很多朋友可能也只是想想,毕竟大家都比较专注程序中的应用逻辑,而忽略了调试器这块的功能研究,自己就定义这种调试方式比较难吧或者没有这种功能而不了了之。大家调试的需求也是一种用户需求,相应工具的开发厂家会根据相应的需求进行开发,所以该功能在大部分主流的开发工具中都已具备,下面我们就验证一下这个功能的可行性
步骤1
1、首先编译好工程,把将要实验的程序完整的烧录一次,必须要保证MCU中正在运行的程序与所要仿真的工程同步,这样调试器通过调试接口获取的程序运行位置信息才能与工程代码中的位置一一对应。
步骤2
2、去掉启动时加载应用程序,并加入Loader.ini文件,主要用于加载已经编译生成的.axf文件到Keil中,从而进行调试。
可能你该问了.axf文件是什么?
其实axf全称为:ARM Executable File,该文件包含bin代码和大量的调试信息,这些调试信息可以被调试器使用,从而定位到我们的C代码
步骤3
3、在调试器Setting选项中,去掉"Reset after Connect",为了调试器链接以后不进行复位动作,从而破坏现场。
步骤4
4、接下来Update Target Before Debugging选择需要去掉,直接调试运行目标不需要勾选,也就不会更新Flash。
步骤5
验证结果
直接在全局变量打印输出的地方放置断点,程序运行到断点处正常停止。
然后我们看一下输出的串口信息数据是否连续,如果打印的数据连续说明程序没有复位,接着反正前正在运行的程序往下执行。