问题描述
使用的工具 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
