本帖最后由 呐咯密密 于 2022-5-13 11:59 编辑
以下**来源于最后一个bug ，作者bug菌
1.调试窘境
经常有朋友在开发中遇到这样的窘境，当单片机程序运行异常以后，由于调试信息做得并不是很全面，导致相应的问题场景非常难分析。当时的你肯定会叹息道:"要是我一直插着仿真器就好了，这个bug还不是分分钟的事~"，每个人都想有颗“后悔药”可吃，然而遇到这种场景也并非绝路。主要是因为大部分朋友插上仿真器以后，调试器在启动时会发出硬件重置信号，应用程序当前的状态都会丢失，包括内存变量、状态等等，对于一些长时间的偶发故障调试更不太友好。此时此刻有一种调试需求是朋友们非常想要的：一旦程序出了问题，我只需要插上仿真器，目标硬件不会复位，而是与我当前所调试的程序同步，类似于仿真程序的时候的“全速运行”，然而通过添加断点，便可查看程序具体的运行状态，内存等等信息，让bug闻风丧胆。很多朋友可能也只是想想，毕竟大家都比较专注程序中的应用逻辑，而忽略了调试器这块的功能研究，自己就定义这种调试方式比较难吧或者没有这种功能而不了了之。大家调试的需求也是一种用户需求，相应工具的开发厂家会根据相应的需求进行开发，所以该功能在大部分主流的开发工具中都已具备，下面我们就验证一下这个功能的可行性：
2.配置过程软硬件环境：
IDE版本: Keil V5.36.0.0 (IAR等主流IDE工具均可) 调试工具版本: jlinkV9 (目前主流调试器基本都已具备) 展示方法： 直接采用全局变量进行累加然后进行串口输出，如果重新连接目标平台，串口输出的全局变量还是顺着之前的计数进行累计，便可以证明MCU没有复位而是从程序运行处开始仿真。 代码实例如下： #include "led.h"
2#include "delay.h"
3#include "key.h"
4#include "sys.h"
5#include "usart.h"
6
7uint32_t Cnt = 0;
8
9/******************************
10*** Function：测试程序
11*** Author ：公众号:最后一个bug
12******************************/
13
14int main(void)
15{
16
17 u16 times=0;
18 delay_init();
19 NVIC_Configuration();
20 uart_init(9600);
21 while(1)
22 {
23 times++;
24 if(times%30==0)
25 {
26 printf("golobal data :\r\n",Cnt++);
27 }
28 delay_ms(10);
29 }
30}
步骤如下： 1、首先编译好工程，把将要实验的程序完整的烧录一次，必须要保证MCU中正在运行的程序与所要仿真的工程同步，这样调试器通过调试接口获取的程序运行位置信息才能与工程代码中的位置一一对应。 2、去掉启动时加载应用程序，并加入Loader.ini文件，主要用于加载已经编译生成的.axf文件到Keil中，从而进行调试。 可能你该问了.axf文件是什么？ 其实axf全称为:ARM Executable File，该文件包含bin代码和大量的调试信息，这些调试信息可以被调试器使用，从而定位到我们的C代码。 3、在调试器Setting选项中，去掉"Reset after Connect"，为了调试器链接以后不进行复位动作，从而破坏现场。 4、接下来Update Target Before Debugging选择需要去掉，直接调试运行目标不需要勾选，也就不会更新Flash。 3.验证结果 直接在全局变量打印输出的地方放置断点，程序运行到断点处正常停止。 然后我们看一下输出的串口信息数据是否连续,如果打印的数据连续说明程序没有复位，接着反正前正在运行的程序往下执行。
通过串口接收数据时间戳可以区分断点和调试运行数据，并且数据都是连续的，说明此调试过程在无需硬件重置即可连接到正在运行的目标。 4.思考 以前我了解到很多朋友觉得仿真程序是把运行程序通过加工调试信息，然后全部下载到MCU，然后进行仿真调试。 这种想法在目前的在线调试中是不太正确的，只需要知道程序运行到哪里，并且查看内部信息、控制程序的运行等，便可以反推定位程序当前所运行的位置和状态，这也是本文开头的前提条件，烧录到Flash上的固件与你即将要仿真的代码工程要保持同步，否则接下来的调试当然就是牛头不对马嘴。 仿真并不是什么神秘的东西，你可以认为就是与MCU内部仿真模块进行通信，从而完成调试信息的交互和控制。
| 
楼主
标题置顶
标题高亮
