嵌入式ARM平台调试方法的讨论

通常情况下我们直接使用JTAG进行嵌入式设备的调试和开发。此方式最简单和直接，且功能强大，能够随时中断处理器，检查程序状态。但是此方式也有缺点：无法长时间跟踪程序的执行情况，对于客户处一些难复现的死机问题很难处理，基本只能依靠静态代码分析。且金融POS来说，由于防拆机制的存在，编写应用时没有办法直接使用JTAG进行调试。因此我们讨论几种新的辅助调试方法。

2. 几种新的调试方法

2.1. 打印寄存器信息

此种方法是最简单的辅助调试方法。在需要打印调试信息的地方加入一个打印函数（或串口打印或屏幕打印）。在程序出错时可以打印当前所有寄存器的数据。这样可以根据PC或LR的值得出当前正在运行的函数和上一个运行的函数，进一步通过编译器输出的Listing文件还可以得到当前和上一个函数C源代码中的行号。更进一步可以编写一个PC应用辅助进行错误分析。

2.2. 打印调用栈

集成调用栈打印比上一种方式能提供更多的信息，在出错时除了当前寄存器的数值，还可以输出完整的调用堆栈。经过实际验证发现，我司目前使用的keil环境下的c编译器默认没有启用frame_pointer机制。即没有一个寄存器指定栈帧开始的位置，这样就无法通过简单的代码实现调用栈的回溯。解决方法是：修改编译选项，在编译时添加参数“--use_frame_pointer”。这样生成的汇编代码会在寄存器R11中保存frame_pointer，也就可以使用简单的代码实现调用栈的回溯和输出。由于嵌入式设备中的运行代码中并没有存储调试信息，因此种方法输出的调用栈就是地址，需要结合map文件或listing文件将其转化为c函数名和行号。同样也可以编写PC软件辅助调试信息的解析和显示。

2.3. 完整栈转储

完整栈转储有比上一种调试方式更高级，使用此种调试方式时应该在设备内部的SPI Flash中开辟出一块固定的存储区域，在程序出错时可以将全部栈数据保存进Flash中。在合适时机（下次开机时或出错的时候直接输出）将保存的栈输出。这样可以结合编译器生成的Listing文件和map文件进行堆栈的分析。由于Listing文件中有每个函数使用栈的大小信息，因此不启用frame_pointer也可以进行调用栈的分析，同时还能还原局部变量的数值。此种方式还有一个巨大的优势，对于程序跑飞的情况，可以从栈底开始正向分析调用栈，这样在堆栈破坏不是太严重的情况下，能够大致找到程序跑飞之前执行的函数，可以很大程度缩小分析跑飞问题时关注函数代码的范围，方便更快找到问题。

2.4. 完整内存转储

此种方法是辅助调试的终极大招，由于嵌入式设备的内存普遍比较小，在KB级别。因此可以在出错时将整个内存保存进设备内部的SPI Flash中，在合适时进行输出，在PC端进行分析。分析得到的数据除了上述所有内容，还可以知道所有全局变量的数值。

此种方法除了以上所述，一定还有更多分析使用方法，受限于我的知识范围，当前仅能想到这些分析方法。欢迎其他同学提出更多的内存转储使用方法。

3. 进行错误处理的时机

刚才在描述调试方式的时候，仅提到在“程序出错时”进行错误处理。实际使用时是程序出错的时机一般有两个：

各种异常处理函数中。对于非法地址指针访问，对齐问题，权限问题，以及在程序跑飞时一般都会触发硬件异常。因此在异常处理函数中进行错误处理是十分自然的。

对于软件死循环的情形，根据程序架构的不同，检测有多种情形：对于某些不开启抢占的多任务环境，可以利用看门狗机制，单独使用一个线程喂狗，如果有某个线程死锁，会造成喂狗线程得不到调度，因此就可以触发看门口中断，在中断中打印当前线程的调用栈即可发现死锁问题。对于单线程运行的前后台系统，可以在每次大循环的最后进行喂狗，如果狗叫则打印堆栈也可以起到同样的效果。对于开启抢占的多任务环境（比如我司售饭机的情况），暂没有想到什么方法能够进行通用的死循环检测。因此只能自行根据代码逻辑在循环中增加喂狗机制和看门口配合使用上述方法发现死锁。

4. 新调试方法的运行原理

上述文字描述了各种辅助调试方法的优缺点和实际，最关键的原理问题并没有介绍，这里我们简单描述一下。

4.1. 栈的作用

栈是实现C语言函数调用的基石。对于每一次C语言的函数调用，汇编代码执行的流程基本上是这样的：

1、调用者将调用子函数时需要的参数放入寄存器或压入堆栈（根据参数数量和大小而定）；

2、调用者将返回地址放入LR寄存器，然后跳转到子函数处开始执行。

3、子函数在栈中备份用到的寄存器（用于退出前恢复其原内容，包括LR和通用寄存器）