美文网首页我爱编程
利用Keil的Call Stack解决Hardfault问题

利用Keil的Call Stack解决Hardfault问题

作者: 真水无香zj01 | 来源:发表于2018-01-27 00:31 被阅读0次

    一、问题的由来

    在调试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!

    相关文章

      网友评论

        本文标题:利用Keil的Call Stack解决Hardfault问题

        本文链接:https://www.haomeiwen.com/subject/lwjgaxtx.html