67/70 MCU中的HardFault_Handler问题

问题描述

使用的工具 KDE-5.11 在调试目标芯片 EFM32 时出现问题,起初是调试铁电驱动,但在单步仿真时到某一步总会不再响应,或者结束仿真时 PC 跳转到了 HardFault_Handler 异常。为了解决这个问题,于是不断地缩减代码,之后发现程序从 startup 开始执行时,一进入 main 函数就会不响应或者跳转到 HardFault_Handler 中,一度怀疑自己的硬件 CMSIS 移植有问题。为了解决这个问题,尝试了多个办法,包括并不仅仅限于更换调试工具,断点调试,评估板代替测试,重新移植底层代码,查看 RAM 占用,修改静态区全局变量占用大小等等。下面总结一些遇到 HardFault_Handler 异常的解决方法。

HardFault_Handler 分析

一般 HardFault_Handler 错误是指 PC 指向了一个无法访问的位置,主要可以分为两种:

  • 内存溢出或者访问越界。这个需要自己写程序的时候规范代码,遇到了需要慢慢排查。
  • 堆栈溢出。增加堆栈的大小。

仿真时,有时会出现 HardFault_Handler 这种错误,这种错误往往会涉及到一些编译运行时的深层次原理,但基本可以肯定的是一般都是 SP,LR,PC 这三个寄存器出了问题,下面介绍这三个寄存器:

  • 堆栈指针r13(SP):每一种异常模式都有其自己独立的r13,它通常指向异常模式所专用的堆栈,也就是说五种异常模式、非异常模式(用户模式和系统模式),都有各自独立的堆栈,用不同的堆栈指针来索引。这样当ARM进入异常模式的时候,程序就可以把一般通用寄存器压入堆栈,返回时再出栈,保证了各种模式下程序的状态的完整性。

  • 连接寄存器r14(LR):每种模式下r14都有自身版组,它有两个特殊功能:

(1)保存子程序返回地址。使用BL或BLX时,跳转指令自动把返回地址放入r14中;子程序通过把r14复制到PC来实现返回,通常用下列指令之一:
            MOV PC, LR 
            BX LR

    通常子程序这样写,保证了子程序中还可以调用子程序。
             stmfd sp!, {lr}
             ……
             ldmfd sp!, {pc}

(2)当异常发生时,异常模式的r14用来保存异常返回地址,将r14如栈可以处理嵌套中断。
  • 程序计数器r15(PC):PC是有读写限制的。当没有超过读取限制的时候,读取的值是指令的地址加上8个字节,由于ARM指令总是以字对齐的,故bit[1:0]总是00。当用str或stm存储PC的时候,偏移量有可能是8或12等其它值。在V3及以下版本中,写入bit[1:0]的值将被忽略,而在V4及以上版本写入r15的bit[1:0]必须为00,否则后果不可预测。

需要研究到底寄存器、函数是如何跳转调用的,我们需要使用 KDE 中的两个仿真工具: Register 和 Call Stack+Locals。Register 中主要观察 SP,LR,PC 三个寄存器的数据,PC永远指向 CPU 正在执行工作的位置,LR 会保存你调用子函数之前的跳转地址,也就是说当子函数完成返回时,会回到 LR 值对应的地址继续执行下面的程序。我这边实验时,能够看出每次执行错误后, PC 会跳转到一个很大的错误地址。

指针跑飞

在 HardFault_Handler 中的 while(1) 设置断点,然后运行,给它触发 HardFault_Handler 的条件,然后到断点处之后,查看 watch 窗口中的 Call Stack+Locals,也就是堆栈以及局部变量,程序执行到哪一句发生的错误,以及当时各个压栈的函数的各个局部变量的值一目了然。一般而言最常出现的就是指针跑飞,数组越界,这两种其实可以看做一个情况,都是指针访问了无权限访问的空间,通过 Call Stack+Locals 窗口往往能够定位到该函数,然后可以采用单步执行,看到具体在哪一步触发了异常。

RAM溢出

这种情况也是我排查的一种情况,编译完成之后,全局变量已经占用了相应大小 RAM 中的静态存储区域,如果你的 MCU 本身不够大,例如我的只有 8K RAM空间,而 COM 的缓冲数组占用了过多的全局变量,这边就存在一定的可能 RAM 不够分配而越界。

底层 CMSIS 问题

因为我的项目是在进入 main 函数一开始就出错了,所以为了排除是不是之前的跳转就有问题,所以重新移植 startup.s 文件

Jlink

不排除调试器存在缺陷,所以更换了调试器,将自己的程序移植到评估板上面运行,进一步验证,直接使用官方自带例程,在评估板上面运行。

inline函数无法捕捉

EFM32 芯片采用 JLINK V9 多次测试多款不同型号的芯片都无法单步执行,单步只能在 while(1) 中执行,一般从 startup 到 main 函数中就会发生错误,开始怀疑是调试工具的问题,通过增加断点部分解决了这个问题,经过评估板测试,查看 RAM 占用,静态区全局变量等查看不断排查,之后发现是共同规律是每次 inline 函数调用某一个普通函数时,单步执行到 return 时,无法找到真实的返回地址。

这边是我主要出现错误的情况,一般较为少见,根本原因在于 inline 函数是类似于宏定义,直接本地展开的,如果使用断点是无法捕捉到的,这边我的 inline 函数中又调用了一个普通函数,因为 inline 函数是原地展开,LR 没有载入它的地址,而每次普通函数在返回时,无法获取到 inline 函数的返回地址,然后就跳转了异常,这本身并不能算是一个问题,在 MCU 正常运行时不会产生任何影响,影响的仅是你的调试过程。另外我个人在调试 SPI 驱动时,因为也调用了固件库自带的 inline 函数,所以导致也没法单步执行这段程序。

小结

虽然这边查出我的问题出现在内联函数上面,但是,以上的集中方法都可以作为常用排查 HardFault_Handler 异常的方法,且一般而言出现指针跑飞的可能性最高。

参考链接:
http://blog.csdn.net/zyboy2000/article/details/7668331
http://www.51hei.com/bbs/dpj-39846-1.html
http://blog.csdn.net/jimmy2013_1_1/article/details/9723461
http://blog.chinaunix.net/uid-26967414-id-3823606.html
http://blog.csdn.net/zhou1232006/article/details/6149548
http://blog.csdn.net/pony_maggie/article/details/5270501
http://wenku.baidu.com/view/f7bf4ad6b14e852458fb576a.html?re=view

你可能感兴趣的:(67/70 MCU中的HardFault_Handler问题)