前言：
在使用STM32 开发时，避免不了各种异常导致进入hardfault。通常如果进入hardfault 的错误容易复现好解决，直接debug调试即可。就怕hardfault 需要几天才能复现，这个时候总不能一直接连电脑debug等着它复现吧，因此需要一个工具能够定位 hardfault 错误，将进入while(1)循环之前将现场的环境保存下来，并且将这些数据通过串口打印或者存储到内部flash，后面在读取出来。
HardFault 产生原因
常见产生HardFault产生的原因大概有如下几类：
- 数组越界操作；
- 内存溢出，访问越界；
- 堆栈溢出，程序跑飞；
- 中断处理错误。
数组溢出
毋庸置疑，程序中使用了静态数组，而在动态传参时数组赋值溢出。或者动态分配内存太小，导致程
序异常。
内存溢出
重点检查RAM区域，程序编译后执行的RAM数据量大小为多少是否可能越界。一般不要设置到极致
的情况，程序中的一些动态数组传参时会导致异常。
计算 RW-data+ZI-data 为需要存储在RAM区域的变量等。
检查程序编译后的.MAP文件。
对应手册，或者编译器查找到对应RAM存储空间区域。找到该区域分析，并对应。
在这种问题下，尤其需要注意：
使用Printf， vsprintf， sprintf 格式化数据导致的内存问题，这些函数使用的内存空间较大，猜测是由
于，该函数采用的拷贝数组的形式转换，内存耗费剧烈。
使用操作系统的若为 设置钩子函数抛出异常，则也会产生该问题。配置操作系统所用空间，包含消
息量，消息队列，邮箱，任务堆栈等。
堆栈溢出
这在使用操作中问题尤其严重，在操作系统中，任务的变量均分配放置在任务所申请的堆栈空间中。
例如FreeRTOS的xTaskCreate、 task. h
创建新的任务并添加到任务队列中，准备运行
Parameters
pvTaskCode
指向任务的入口函数. 任务必须执行并且永不返回 (即：无限循环).
pcName
描述任务的名字。主要便于调试。最大长度由configMAX_TASK_NAME_LEN.定义
usStackDepth
指定任务堆栈的大小 ，堆栈能保护变量的数目- 不是字节数. 例如，如果堆栈为16位宽度，
usStackDepth定义为 100, 200 字节，这些将分配给堆栈。堆栈嵌套深度（堆栈宽度）不能超多最
大值——包含了size_t类型的变量
pvParameters
指针用于作为一个参数传向创建的任务
uxPriority
任务运行时的优先级( 0 : 优先级最低)
pvCreatedTask
用于传递一个处理——引用创建的任务
返回:
pdPASS 是如果任务成功创建并且添加到就绪列中，另外错误代码在projdefs. h文件定义.
所创建的任务需要指定堆栈大小，那么堆栈申请不足，则会出现异常，针对该问题可启动系统的钩子
函数HOOK函数，抛出该异常。
中断处理异常
程序中开启了某些中断，例如USART,TIMER,RTC等。
但在程序执行中，满足中断条件，但并未能查找到该部分对应的中断服务函数，则可能会出现该异
常
HardFault 分析方法
常见的分析方法是：发生异常后之后，首先查看LR寄存器中的值，确定当前使用堆栈为MSP或PSP,然后找到相应堆栈的指针，并在内存中查看相应堆栈里的内容。由于异常发生时，内核将R0-R3、R12 Returnaddress、PSR、LR寄存器依次入栈，其中 Return address即为发生异常前PC将要执行的下一条指令地址。
CmBacktrace
CmBacktrace （Cortex Microcontroller Backtrace）是一款针对 ARM Cortex-M 系列 MCU 的错误代码自动追踪、定位，错误原因自动分析的开源库。主要特性如下：
- 支持的错误包括：
- 断言（assert）
- 故障（Hard Fault, Memory Management Fault, Bus Fault, Usage Fault, Debug Fault）
- 故障原因 自动诊断 ：可在故障发生时，自动分析出故障的原因，定位发生故障的代码位置，而无需再手动分析繁杂的故障寄存器；
- 输出错误现场的 函数调用栈（需配合 addr2line 工具进行精确定位），还原发生错误时的现场信息，定位问题代码位置、逻辑更加快捷、精准。也可以在正常状态下使用该库，获取当前的函数调用栈；
- 支持 裸机 及以下操作系统平台：
- RT-Thread
- UCOS
- FreeRTOS（需修改源码）
- 根据错误现场状态，输出对应的 线程栈 或 C 主栈；
- 故障诊断信息支持多国语言（目前：简体中文、英文）；
- 适配 Cortex-M0/M3/M4/M7 MCU；
- 支持 IAR、KEIL、GCC 编译器；
基于 MDK 的 CmBacktrace 库使用流程
基于MDK的移植方法按如下步骤进行：
步骤一 添加cm_backtrace库文件到MDK中
把cm_backtrace文件夹复制到我们的工程目录下，并添加至keil工程中。
步骤二 添加头文件、勾选C99模式
步骤三 编译和调试
首先， cmb_cfg.h文件按以下提示配置修改。
这时候编译有一个错误， 这是因为cmb_fault.c与at32f4xx_it.c中的HardFault_Handler函数重定义：
需要把at32f4xx_it.c中的HardFault_Handler函数屏蔽掉。
初始化 cm_backtrace
这里的Appname 需要与输出的文件名一致。
将异常信息写入内部flash
正常如果设备有串口，进入hardfault 时会将错误信息打印出来，如果没有串口的话，我们就需要将错误信息写入内部flash，通过读取内部flash信息就可以知道上一次进入 hardfault 时的状况，然后再使用 addr2line工具查看错误代码。
添加写入flash信息代码：
这样下次可以通过st-link 定位到固定地址读取信息。
