利用Keil的Call Stack解决Hardfault问题

一、问题的由来

在调试STM32程序时，遇到了程序突然运行到HardFault中断的问题。之前也遇到过类似的情况，大多时凭借猜想解决问题，有时候不能够很快的定位问题来源。今天在调试时，学到了一个有效的调试方法，可以帮助我快速定位问题点。
先贴出大神的博客：http://blog.sina.com.cn/s/blog_4aa25f130102v0m8.html

二、关于Hardfault

Cortex-M3/4的Fault异常是由于非法的存储器访问（比如访问0地址、写只读存储位置等）和非法的程序行为（比如除以0等）等造成的。常见的4种异常及产生异常的情况如下：
Bus Fault：在fetch指令、数据读写、fetch中断向量或中断时存储恢复寄存器栈情况下，检测到内存访问错误则产生Bus Fault。
Memory Management Fault：访问了内存管理单元（MPU）定义的不合法的内存区域，比如向只读区域写入数据。
Usage Fault：检测到未定义指令或在存取内存时有未对齐。
Hard Fault：在调试程序过程中，这种异常最常见。上面三种异常发生任何一种异常都会引起Hard Fault，在上面的三种异常未使能的情况下，默认发生异常时进入Hard Fault中断服务程序。
需要注意的是，在默认复位初始化时，Hard Fault使能，其它三者不使能，因此当程序中出现不合法内存访问（一般是指针错误引起）或非法的程序行为（一般就是数学里面常见的除0）时都将产生Hard Fault中断。

三、问题分析

在网上查找相关资料，发现这种问题主要有以下原因：
1 内存溢出或者访问越界，通常为数组或结构体访问越界。这个需要自己写程序的时候规范代码，遇到了需要慢慢排查。
2 堆栈溢出。增加堆栈的大小。
3 在uCos-III系统中，任务切换时要关中断。
4 没有打开相应的硬件模块但操作了相应的硬件而导致了错误
5 Jlink的问题，禁止用Jlink供电就可以了。在Jlink commander中输入power off，
6程序在添加全局变量的时候会出现sprintf 输出的浮点数不正常，因此尽量不用sprintf函数。
7使用了非法的指针，比如说空指针
u8 *p = null;
*p = 1; 把0地址的数据强制设置为1， 不错才怪
8使用 OS_ENTER_CRITICAL();
使用了 OS_ENTER_CRITICAL(); 却忘了OS_EXIT_CRITICAL(); 退出临界区
特别是在这个函数OS_ENTER_CRITICAL(); 调用了子函数 也有的这类情况，很容易忘记关闭的这样就造成了“死机现象”
因此如果调用的话 建议在函数中加入OS_CPU_SR cpu_sr = 0u;局部变量 在管理临界区 os的内核程序也是这么用的 ，而且要注意，临界区一般用于全局变量的写操作，时间要非常快的，任务中的变量可以不用添加 。

结合本项目的实际情况，我认为内存访问错误的概率最大。

四、排查过程

通过学习大神的文章，本次排查问题主要利用了MDK中的Call Stack窗口。

1 在stm32f10x_it.c中，添加软件断点，一旦调试时出现Hard Fault则会在停在断点处。

image.png

2调出Call Stack

image.png

3运行程序，直到出现bug

image.png

如上图所示，Call Stack记录了出现异常前，单片机调用的一些函数，从下到上，很像是飞机的黑匣子。
可以看到，我的程序运行到了0x08004F40地址后，直接跳到了HardFault。而这个地址的上一步执行了Data_frame_parsing这个函数。首先定位到出错的地址，右键单击那个地址，选择“Show Caller Code”就可以定位过去。

image.png

定位到了这一行，对一个内存地址进行拷贝操作，由于源地址和目标地址都是在堆空间上malloc
出来的，于是我很快想到会不会是在拷贝前，由于某种原因源地址被free掉了，所以出现了内存访问错误？

image.png

于是跑到这个函数调用的地方，果然发现紧跟着这个函数下面有一个free。于是改成了
while(Data_frame_parsing(p_wifi_rcv_frame) != 0);
free(p_wifi_rcv_frame);
大意就是等程序运行完，再释放内存空间。于是再仿真。。。发现依然进了Hardfault。

然后我发现，数据帧里有点不对劲。

image.png

表示数据帧长的这个字节，居然是0x00！
然后我马上意识到，我申请的这段内存空间大小，是根据data_len这个成员的值来确定的。
由于某种原因（通信丢包）这个地方写入了0，于是申请的空间大小就是0，之后再来访问这段内存，肯定就出错了！

确定了问题，接下来修改代码。
在申请内存空间之前，先判断一下这个数，是不是在一个合理的范围之内，如果是，就分配空间，如果不是，就说明数据帧出问题了，直接跳出。

image.png

再编译，运行！OK了！再也没有出现过Hardfault错误。

五、总结

这个故事告诉我们。在写一个程序的时候，对输入的参数进行合法性的检查，是非常重要的，可以省去很多不必要的麻烦。
在遇到Hardfault错误时，可以用一个很直观的方式观察到是哪里出现了问题，可以帮助我们快速的定位错误。解决bug！