MCU HardFault问题查找和破解方法
时间：2021-10-19 16:10:37
手机看文章
扫描二维码
随时随地手机看文章
[导读]一、HardFault产生原因和常规分析方法二、HardFault解决方法分析三、HardFault回溯的原理四、操作分析流程：心里明白徒手分析法CmBacktrace天龙大法五、总结一、HardFault产生原因和常规分析方法在嵌入式开发中，偶尔会遇到HardFault死机的异...
一、HardFault产生原因和常规分析方法二、HardFault解决方法分析三、HardFault回溯的原理四、操作分析流程：
理解了以上的Hard Fault回溯的原理，下面按以上提到的两种思路来实操一下。
Step1：判断SP是MSP还是PSP，找出SP地址。在产生Hard Fault异常后，首先在序号2中选择“ CPU register”，不要使用默认的 “CPU register ”，否则默认只会显示MSP，不会显示PSP。然后查看序号3中LR寄存器的值表示判断当前程序使用堆栈为MSP主进程或PSP子进程堆栈，显然LR=0xFFFFFFF9 的bit2=0，表示使用的是主栈，于是得到SP=序号4中的SP_main=0x20005620；Step2：找出PC地址。如序号5演示，打开memory串口，输入SP的地址可以找到异常产生前压栈的8个寄存器，依次为 xPSR、PC、LR、R12以及 R3~R0，序号6中便可以找到出错前PC的地址位0x00008a06；Step3：找出代码行数。如序号7演示，打开汇编窗口，在“go to”串口输入PC地址，便可以找到具体出错时代码的位置，如序号8演示，可以发现，轻松愉快的找到了导致Hard Fault的非对齐访问的代码行；
Step5： 配置打印信息的输出位置，建议的做法是输出到物理串口，可以方便的离线分析记录log, 但实验中为了简化以及通用(有些时候硬件设计上可能没有留硬件串口)，直接把打印信息输出到IAR的Terminal IO进行显示(Kinetis SDK如何修改代码，使能打印信息输出到IAR的Terminal IO的做法详见另外一篇文档)。Step6： 运行代码，观察打印结果，可以看到打印信息中包含出错的任务名称、出错前的任务压栈的8个通用寄存器名称和内容，从图中可以一目了然的找出出错的PC指针，如果进一步去结合汇编代码可以清晰的看到其能够准确定位到代码出错的位置。
到此，使用CmBacktrace大法不轻松但很愉悦的定位到问题点了。
- 心里明白徒手分析法
- CmBacktrace 天龙大法
一、HardFault产生原因和常规分析方法
在嵌入式开发中，偶尔会遇到Hard Fault死机的异常，常见产生Hard Fault的原因大致有以下几类：- 数组越界和内存溢出，譬如访问数组时，动态访问的数组标号超过数组长度或者动态分配内存太小等；
- 堆栈溢出，例如在使用中，局部变量分配过大，超过栈大小，也会导致程序跑飞；
- 在外设时钟开启前，访问对应外设寄存器，例如Kinetis中未打开外设时钟去配置外设的寄存器；
- 不当的用法操作，例如非对齐的数据访问、除0操作(默认情况下M3/M4/M7，除0默认都不会触发Fault，因为ARM内核CCR寄存器DIV_0_TRP位复位值为0，而对M0来说DIV_0_TRP位是reserved的，也不会产生Fault错误)、强行访问受保护的内存区域等；
尽管本测试是针对NXP KW36芯片的，但该步骤和方法也适用于其他的Arm Cortex-M内核MCU；
二、HardFault解决方法分析
笔者在实际支持客户过程中也遇到这种困惑，网上的介绍资料比较零散，理论很多，很少详细描述实战操作的步骤，借助同事的点拨，摸索出两种定位Hard Fault问题的方法，在实际使用中操作性也很强，此处分别做一介绍。- 第一种：心里明白徒手分析法，就是在了解Hard Fault出错原理以及程序调用压栈出栈原理的基础上(当然按照本文的练就心法，心里不明白也可以)，在Debug仿真模式下徒手去回溯分析CPU通用寄存器（LR/MSP/PSP/PC），然后结合调试IDE去定位到产生Hard Fault的代码位置；
- 第二种：CmBacktrace 天龙大法，该方法是朱天龙大神针对 ARM Cortex-M系列MCU开发的一套错误代码自动追踪、定位、错误原因自动分析的开源库，已开源在Github上，该方法支持在非Debug模式下，自动分析定位到出错的行号，无需了解复杂的压栈出栈过程。
三、HardFault回溯的原理
为了找到Hard Fault 的原因和触发的代码段，就需要深刻理解当系统产生异常时 MCU 的处理过程: 当处理器接收一个异常后，芯片硬件会自动将8个通用寄存器组中压入当前栈空间里（依次为 xPSR、PC、LR、R12以及 R3~R0），如果异常发生时，当前的代码正在使用PSP，则上面8个寄存器压入PSP，否则就压入MSP。那问题来了，如何找到这个栈空间的地址呢？答案是SP, 但是前面提到压栈时会有MSP和PSP，如何判断触发异常时使用的MSP还是PSP呢？答案是LR。到此确定完SP后，用户便可以通过堆栈找到触发异常的PC 值，并与反汇编的代码对比就能得到哪条指令产生了异常。总结下来，总体思路就是：首先通过LR判断出异常产生时当前使用的SP是MSP还是PSP，接着通过SP去得到产生异常时保存的PC值，最后与反汇编的代码对比就能得到哪条指令产生了异常。回到前面的第二个问题，如何通过LR判断当前使用的MSP还是PSP呢？参见如下图，当异常产生时，LR 会被更新为异常返回时需要使用的特殊值（EXC_RETURN），其定义如下，其高 28 位置 1，第 0 位到第3位则提供了异常返回机制所需的信息，可见其中第 2 位标示着进入异常前使用的栈是 MSP还是PSP。
四、操作分析流程：
理解了以上的Hard Fault回溯的原理，下面按以上提到的两种思路来实操一下。1. 心里明白徒手分析法
前面提到，为了清晰的展现这个过程以及每个参数之间的关系，尽量把整个流程按照顺序整理到一张图中，如下图1。示例中使用的是KW36 temp_sensor_freeRTOS例子（什么例子不重要，该方法也适用于其他的MCU系列），在main函数中通过非对齐地址访问故意制造Hard Fault错误，代码如图中序号1，当程序试图访问读取非对齐地址0xCCCC CCCC位置时程序就会跳入到Hard Fault Handler中，那具体是如何通过堆栈分析定位到出错代码是在n=*p这一行呢？具体步骤如下：Step1：判断SP是MSP还是PSP，找出SP地址。在产生Hard Fault异常后，首先在序号2中选择“ CPU register”，不要使用默认的 “CPU register ”，否则默认只会显示MSP，不会显示PSP。然后查看序号3中LR寄存器的值表示判断当前程序使用堆栈为MSP主进程或PSP子进程堆栈，显然LR=0xFFFFFFF9 的bit2=0，表示使用的是主栈，于是得到SP=序号4中的SP_main=0x20005620；Step2：找出PC地址。如序号5演示，打开memory串口，输入SP的地址可以找到异常产生前压栈的8个寄存器，依次为 xPSR、PC、LR、R12以及 R3~R0，序号6中便可以找到出错前PC的地址位0x00008a06；Step3：找出代码行数。如序号7演示，打开汇编窗口，在“go to”串口输入PC地址，便可以找到具体出错时代码的位置，如序号8演示，可以发现，轻松愉快的找到了导致Hard Fault的非对齐访问的代码行；
2. CmBacktrace 天龙大法
Step1： 从天龙大神的Github下载CmBacktrace的源代码包，拷贝cm_backtrace目录下的4个文件以及cmb_fault.s文件到KW36 IAR工程中，如下图序号2标识，并添加相应的搜索路径；Step2： 根据应用修改cmb_cfg.h的配置，需要配置的选项包括print打印信息的重定义，是否需要支持OS，OS的类型(RTT、uCOS以及FreeRTOS)，ARM内核的类型，打印输出语言类型等；本实例中使用了错误信息中文打印以及FreeRTOS，所以配置如下图序号2标识。Step5： 配置打印信息的输出位置，建议的做法是输出到物理串口，可以方便的离线分析记录log, 但实验中为了简化以及通用(有些时候硬件设计上可能没有留硬件串口)，直接把打印信息输出到IAR的Terminal IO进行显示(Kinetis SDK如何修改代码，使能打印信息输出到IAR的Terminal IO的做法详见另外一篇文档)。Step6： 运行代码，观察打印结果，可以看到打印信息中包含出错的任务名称、出错前的任务压栈的8个通用寄存器名称和内容，从图中可以一目了然的找出出错的PC指针，如果进一步去结合汇编代码可以清晰的看到其能够准确定位到代码出错的位置。
到此，使用CmBacktrace大法不轻松但很愉悦的定位到问题点了。
下载文档
