两周前，本站有一篇杰作“那个讨厌的HardFault，看你往哪里跑！”，今天开始我来更深入地探讨一下这个Fault机制。
人们常说，幸福的家庭都是相似的，不幸的家庭各有各的不幸。然而，如果是咱们MCU工程师的家庭，不幸之处却也常常相似——主要成员常年被各种软、硬件结合的玄妙问题所虐，胸有邪火，心无人伦，眼睛盯的是屏幕和板子，手上写的不是人话而是C语言，屁股底下抹胶水，积累各种家庭矛盾，也让局部地区灾害多发。哎，这晦涩的嵌入式开发还真是让人爱恨交加呀！ 不过，如果是在Cortex-M上干活，却有一个专属的“福报”，利用好的话能大大地解救咱们于水火。那就是时常陪伴我们左右，却想说爱你不容易的——“Hard Fault”！ 说Hard fault是福报，倒不是在于它为咱们带来了更多的996，恰恰相反，而是它给咱们带走了更多的996。HardFault就像是比特世界里的超级巡警，让咱们撸码时播下的很多病虫害失去了肆意破坏的机会，刚开始作祟，就被逮个正着了。而早年很多单片机的架构，因为CPU缺少异常处理的机制，就算程序执行非法指令、访问错误的地址，也置若罔闻，放任它们搞花样百出的破坏，而可怜的工程师就只能从更扑朔迷离的后果中，自己绞尽脑汁地探求原因了。其实，在主流和高档Cortex-M系列CPU上，如M3, M4, M7, M33，以及最新的M55，Hard fault是一众faults的“民意代表”（在M0, M0+, M22上，则只有Hard fault）。强大的Cortex-M CPU能够识别出多达15种异常的执行状态，并且把它们分为三大类fault，分别对应：总线事务出错 (Bus Fault)，
访问禁止的地址(MemManage Fault)，
以及对CPU的无效的使用方式(Usage Fault)。
这三大类fault在向量表中都有自己的一席之地，指派处理函数。
不过，大多数系统中常常只有单个异常处理的总衙门，所以很多程序都按照默认的设置，禁用了各自“基层”fault入口。这些fault于是就由Hard Fault来代表了，并且由Hard Fault的处理函数统一接管。就算它们各自已经启用，只要是由于优先级不够高之类的原因无法马上执行，也会上诉到Hard fault那里。
Bus fault, MemManage fault, Usage fault, 以及它们的总代表——Hard fault，好比是程序中各种病虫害的四大缉事厂，协助咱们在Cortex-M的比特世界中除四害！
Hard Fault的处理函数可不是好当的差事，如果说要应付15种异常状态时就够让小心肝发颤了，那要是这些状态有些还可以互相迭加呢，这还让不让人活了？
俗话说，風多不痒，债多不愁。既然这个Hard Fault是这么个烫手山芋，干脆就束手打转吧！君不见很多程序框架的模子中，Hard Fault的处理函数不就是用个“B .”来原地打转吗？
体贴一点的，HardFault处理程序会收集现场的寄存器并打印出来，到串口上，或者像上一篇那样打印到gdb神器的控制台上，然后，就没有然后了…… 哦不，然后就靠你了。
说到这里不能不衷心地表一表armink同学，他开发了一套叫cmbacktrace的开源库，带来保姆级的HardFault辅助分析功能。不但能以人类可读的方式打印出是哪一种异常状态；还从栈中往前翻出在出事时的层层函数调用关系。
不过，辅助程序再强大，也只是带给我们更多线索，无法替代工程师的思考，还是得面对15种异常状态和它们的组合。
别怕，咱们肩膀上顶着世界上最强大的深度神经网络——自己的大脑！可以把程序中两手一摊的麻烦事给接过来。而且，虽说CPU能捕捉15种异常状态，并且还可以叠加，看似千变万化，实则有规可循。还有最重要的，那就是程序中病虫害的高发地，常常是指针误用、数组越界、地址不对齐、栈溢出这些常见的情况。这其实也常常是拜C语言的“一切相信程序员”的哲学所赐：咱们在享受至高无上的折腾系统的权力时，也要承受一丝不苟的伺候系统的义务。
那么，接下来，就让小编和大家一起揭开调试Hard Fault的不太神秘的面纱，顺着CPU提供的线索，把事故现场尽量完整地还原出来。
故事的第一步，就是要知道CPU在发生Fault时，都干了些什么。
其实说来也简单，Fault是异常的一种，而CPU处理异常的流程和处理中断几乎是一样的。其中的重头戏，都是自动地把8个寄存器压入到出事前正在使用的栈区（可能有同学会问如果是栈指针无效导致的fault呢，嗯，这个后面咱们再杠），然后改用由MSP所指示的主栈区，最后跳转到由向量表中HardFault入口指定的地址处执行。这8个寄存器都是什么，各自压在哪里，咱们最好烂熟于心。这里小编整理了一个图：
这里利用了KEIL的一个强大的调试功能：通过在Memory Window中输入寄存器的名字，就能自动跳到寄存器中的地址。
与中断不同的是， CPU还会根据具体的异常原因来设置几个重要的寄存器，来告知这15种异常状态中的哪些种发生了，这个寄存器就是大名鼎鼎的CFSR，位于CPU的SCB空间。
在CMSIS库中，可以使用SCB->CFSR来读取。CFSR中有很多位，散落在32个位之中，看起来零乱不堪。更何况调试工具一般用8个16进制数来表示它们，让人类解码显然是强人所难。
于是，包含cmbacktrace库在内的一些体贴点的HardFault处理程序，把它们转换成人类易读的形式了。常见的IDE也常常有些可视化的处理。
这不，在KEIL下的调试会话中，就可以打开”Fault Reports”窗口，像这样：
上图中粉红色背景的就是这15种异常情况，哪个打了勾，就表示哪种异常情况发生了。备注：细心的读者可能发现其实图上有17个框，但是”BFARVALID”和“MMARVALID”用于提供额外信息，并不是独立的错误状态，不能算。 有了事故现场，就可以继续分析啦，就算找不出最终根源，根据这些线索一般也能找出直接原因。不过，这也是难啃的部分，好在实际情况是几种常见情况出现得最频繁。由于篇幅所限，这部分就容小编在后面一一展开介绍吧，一定要看哦！
分享至：恩智浦MCU加油站
