STM32 程序卡着不动，可能是发生了硬件错误，进入了HardFault_Handler处理程序中

1.前言

STM32 程序卡着不动，可能是发生了硬件错误，进入了HardFault_Handler处理程序中。

2.问题描述

调试STM32程序时，遇到一个很古怪的问题。程序本应输出CRC的内容。结果没有任何打印输出。通过缩小问题范围，定位应该是hexStringToCRC16函数中出了问题。

DEBUG模式，单步调试时，发现程序卡在sscanf函数不动了。再调试发现进入了硬件错误，while(1)循环，所以一直卡着不动了。

该函数就是把hexStr中的数据放入data中，而data是在堆上申请的一块空间。刚开始怀疑：是不是data空间申请的小了，下标访问越界，想了下，不是。

把问题现象描述了一下，在大模型中查找答案。没想到，大模型给了我惊喜。



看到提示，我就想是不是STM32 堆空间不够用了。就把堆空间扩大了一倍。然后问题解决。

3.问题解决

另外，由该问题引发的思考。
重要！
当发生硬件错误后，程序进入了硬件错误处理流程。如果HardFault_Handler采用默认配置，没有修改，就进入了死循环中。因此，开发者应当根据具业务需要，重写该函数。比如，当发生硬件错误中断时，让程序复位，或者 对异常做些处理，走入专门的异常处理流程中。


2024/10/25日更新
STM32中堆栈大小设置不合适，可能触发HardFault硬件中断。

如下图所示，

根据问题现象，初步还以可能是程序中 定义了大量的临时变量，导致栈空间不够了，而程序在跳转到一个函数时，需要操作栈空间，会有压栈出栈的操作，所以有可能是栈空间不够了，从而产生了HardFault中断。
最后定位到是一个临时变量，申请的空间太大了，改小后，程序正常。