需要补充的知识点: - Cortex-M3相关寄存器的作用；
- Cortex-M3的双堆栈机制；
- 从用户模式到中断服务例程寄存器的入栈和出栈机制等；
- fault 分类以及各自诱因等。
以上这几点知识大家都可以在<Cortex-M3权威指南>上找到，并且非常的通俗易懂，bug菌就不在这里重复"造轮子"了，如果有些小伙伴平时使用的并不是stm32,所需补充的知识其实大同小异，找到对应芯片内核参考手册，然而根据如上的几个方面进行分析即可。
3
排查原理 对于常规的仿真器调试一旦程序进入HardFault_Handler，那么程序便卡在了中断服务程序中的死循环中，不太熟悉内核的小伙伴一定希望"如果仿真器能够有程序倒退功能该多好呀"，也就说大部分的硬件异常只需找到主程序的进入点基本上就能定位具体的fault原因。
可惜的是目前仿真器并没有此类功能，程序是一直往下执行的，对于开发人员倒是可以通过编程让程序回到入口点，不过处理相对比较麻烦，不过我们可以通过程序运行的各个状态推导出之前的程序的运行状态。
然而异常中断本质上和普通的定时器中断等等并无差别，那么在中断触发前必然是要保存现场，运行完中断服务函数以后需要恢复现场，然后继续运行之前的程序，同样当触发HardFault同样需要保存现场，那么完全可以根据系统所保存的现场信息推导出进入异常的入口点。
那么所有的问题都归结到触发中断系统是如何保存中断现场，要回答这个问题大家得看看上面所提到的几点知识。那么下面作者就以两个开源项目中该部分的处理为大家简单介绍一下如何排查fault。
3、RTT中的处理
RTT系统中对HardFault_Handler进行了比较详细的处理，基本上可以把这块参考过来，下面bug菌画了个流程图方便大家阅读：(如下图所示)
代码概要分析: 1、代码碎片1 上面代码实现的是流程图左半部分，很多小伙伴发现r0~r3、r12，lr，pc等等几个寄存器并没有入栈，其实这几个寄存器是硬件上自动压入堆栈中了，不需要我们手动压入。 为什么需要判断MSP和PSP呢 ? 这个问题大家可以参考<Cortex-M3权威指南>里面的双堆栈机制，一般在RTOS中任务中使用的PSP，而中断中使用的是MSP，但我们进入中断服务函数以后其堆栈指针变成了MSP，为了能够获得任务状态下产生的异常，我们需要找到之前的PSP然后获得其自动入栈的寄存器数据来进行分析，自动入栈的PC和LR都是我们用来定位异常前程序位置的重要寄存器。特别是LR是调用子程序时存储返回地址，从而可以定位发生异常的位置。 2、代码碎片2
上图是调用的异常处理函数，其中参数来自r0寄存器的传递(可以查找ARM的函数调用传参形式)，那么这个结构体指针参数应该是与入栈寄存器是一一对应的(如下图所示)，这样我们便可以通过该指针获得相应的寄存器数据并打印出来，这样对于一些不能使用仿真器的场合是再好用不过了。
3、代码碎片3 该部分的处理就是所画流程图的右侧部分实现，其中hard_fault_track函数中主要就是根据具体的每种fault类型寄存器分析fault的原因(其中每个寄存器中的每个位代表什么故障原因都在权威指南中有详细说明)。
好了，那么RTT中对HardFault_Handler的处理Bug菌就讲到这里，其输出的相关信息，通过把源程序仿真查看汇编与C的映射栏进行定位异常前的代码位置，进而进一步分析代码。如下图Keil中的汇编与C映射窗口，可以通过直接查找Code地址来定位C代码。
4、开源故障诊断-"CmBacktrace"
cmbacktrace是amink开源的一个ARM Cortex-M 系列 MCU 错误追踪库，其可以支持stm32不同系列的内核fault分析，同时也支持不同的RTOS分析，比如RTT，FreeRTOS，Ucos。
通过包含如上几个文件即可加入到对应的项目工程用于分析故障，其具体的实现思路是与RTT类似的，这里就不具体分析了。 不过相对功能比较丰富，比如输出错误现场的函数调用栈，也可以在正常状态下使用该库，获取当前的函数调用栈，从而可以更加详细的了解程序运行情况，大家可以参考学习顺便可以了解一下Cortex内核的相关知识，作者也简单的跑了一下例程,其运行结果如下:
| 
楼主
标题置顶
标题高亮
