keil、IAR下如何解决HardFault_Handler中断问题

HardFault_Handler中断

HardFault_Handler硬件中断，是单片机中经常出现的一种异常问题。出现 HardFault_Handler 的原因主要有3类：
内存溢出或者访问越界：由于程序中申请的内存超出了系统的可用内存，或者申请的内存在使用过程中未被正确释放。这种情况会导致系统无法为其他请求分配足够的内存，甚至可能导致系统崩溃。访问了数组范围之外的内存位置或使用野指针，也会导致HardFault_Handler错误。
堆栈溢出：通常发生在函数调用或数组访问时。当函数内部的数组过大，或者递归调用层次太深时，就可能发生堆栈越界。
数组越界：（这次遇到的就是数组越界）
硬件故障：如果硬件出现故障，例如电源干扰、连接器故障或传感器故障等，可能会导致HardFault_Handler错误。

IAR如何定位问题

方法一：

直接在HardFault_Handler中断处打断点，就知道大概是哪些函数调用导致的这个问题

方法二：

移植，CmBacktrace 根据堆栈中解析出来的PC指针，就可以使用addr2line命令解析出来是在哪一行出问题了。皆可以打印出backTrace信息，可以直观的看到PC指针，而且还可以知道是什么问题导致进入到HardFault_Handler，非常好用省去了自己查阅手册的麻烦。

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 编译器；

为什么选择 CmBacktrace

入门新人 ：对于从 C51 、MSP430 等简单单片机转而使用更加复杂的 ARM 新人来说，时不时出现的 “hard falut” 死机会让新人瞬间懵掉。定位错误的方法也往往是连接上仿真器，一步步 F10/F11 单步，定位到具体的错误代码，再去猜测、排除、推敲错误原因，这种过程十分痛苦。
熟练老手 ：慢慢的大家知道可以通过故障寄存器信息来定位故障原因及故障代码地址，虽然这样能解决一小部分问题，但是重复的、繁琐的分析过程也会耽误很多时间。而且对于一些复杂问题，只依靠代码地址是无法解决的，必须得还原错误现场的函数调用逻辑关系。虽然连接仿真器可以查看到的函数调用栈，但故障状态下是无法显示的，所以还是得一步步 F10/F11 单步去定位错误代码的位置。另外，还有两种场景，

1、很多产品真机调试时必须断开仿真器
2、问题确实存在，但是极难被重现
所以定位这类问题就显得难上加难。

如何使用CmBacktrace

cmBackTrace移植CmBacktrace
通过下边的图对比可知，和上边出问题的函数移植，这也是iar相对方便的地方。
这个方法更适用于keil，下边只是为了验证移植CmBacktrace是否成功

问题分析：

异常数据，导致组据越界
char buffer[20];//数组小了

Keil环境下STM32定位hardfault位置方法

参考文章
https://blog.csdn.net/u014448875/article/details/125654843
https://blog.csdn.net/weixin_43176196/article/details/135298947
博文1：https://blog.csdn.net/electrocrazy/article/details/78173558
博文2：https://www.cnblogs.com/dylancao/p/11142205.html