【STM32程序调试与优化指南：解决数组越界与HardFault错误的全攻略】

问题描述

在项目开发过程中，我们遇到了一个棘手的问题：单片机只接受了一次数据后便不再接收。进一步调试发现，程序在接收了第一个数据后卡在了 HardFault_Handler 函数中。程序卡在 HardFault_Handler 函数

原因分析

经过进一步调试，发现问题是由于一个分函数 函数1 导致的。这个函数被调用在定时器中断中，导致数组越界访问。

void 函数1()
{
    int s[5],i;
    for( i=0;i<10;i++)
    {
        s[i]=i;
    }
}

进一步的调试揭示了另一个问题：尽管接收数据的功能仍然存在，但接收到的数据却出现了异常。具体来说，接收到的数据中有一部分是连续的“01 01 01 00”，这显然是不正常的。为了找出这个问题的原因，我们不得不对程序进行更深入的修改和调试。

在不断的修改过程中，我们又遇到了一个新的问题：即使没有进入中断，存放接收数据的数组RX_buf的数据仍然在发生变化。这让我们感到困惑，因为我们不确定这种变化是如何发生的。最终，在同事的帮助下，我们发现问题的根源在于【数组越界访问】，也就是[函数1]导致的。

所谓的数组越界，简单地讲就是指数组下标变量的取值超过了初始定义时的大小，导致对数组元素的访问出现在数组的范围之外，这类错误也是 C 语言程序中最常见的错误之一。

详细请看——>数组越界及其避免方法 C/C++

在用Keil对STM32的程序进行仿真时程序有时会跑飞，停止仿真程序会停在HardFault_Handler函数里的死循环while(1)中。这说明STM32出现了硬件错误。

为什么会产生HardFault_Handler

/**
  * @brief  This function handles Hard Fault exception.
  * @param  None
  * @retval None
  */
void HardFault_Handler(void)
{
    /* Go to infinite loop when Hard Fault exception occurs */
    while (1)
    {
    }
}

STM32出现硬件错误可能有以下原因：

(1)数组越界操作；

(2)内存溢出，访问越界；

(3)堆栈溢出，程序跑飞；

(4)中断处理错误；

遇到这种情况，可以通过以下几种种方式来定位到出错代码段。

解决方法

方法1：利用STM32的LR寄存器调试HardFault错误

HardFault_Handler 函数的 while(1) 处打调试断点，程序执行到断点处时点击“STOP”停止仿真。
在 Keil 菜单栏点击“View” -> “Registers Window”，查看 R14(LR) 的值。
根据 R14(LR) 的值，确定当前堆栈指针是 MSP 还是 PSP。
在 Keil 菜单栏点击“View” -> “Memory Windows” -> “Memory1”，输入 MSP 的值，找到对应的地址。
在 Keil 菜单栏点击“View” -> “Disassembly Window”，输入地址，找到对应的代码。

举例：

1.查看LR的值

首先要查看R14(LR)的值，确定当前堆栈指针是MSP还是PSP。

LR = 0xFFFFFFF9 为主堆栈（MSP），LR = 0xFFFFFFFD为线程堆栈（PSP）。

图中为0xFFFFFFF9，即MSP主堆栈。

2.根据MSP或PSP找到返回地址

MSP的值为0x200017C8,查看这个地址

要知道MSP入栈的顺序，R0、R1、R2、R3、R12、返回address、PSR、LR

我们想要的东西就是返回address，返回address就是发生异常前PC将要执行的下一条指令地址，即第六个：0x00008CCF

3.查看返回地址的函数

双击，查看map文件，找到0x00008CCF大概的位置

最后进入这个函数并锁定问题

HardFault调试的思路

在遇到HardFault异常时，通过在断点处检查LR的值，可以分析程序状态。LR在异常后通常为0xFFFFFFFx，指示异常前的返回地址。根据LR的ReturnStack判断PSP或MSP，找到栈顶获取返回地址，从而追溯到异常发生前的代码位置。在MDK中，利用Memory和DisassemblyWindows可以辅助这一过程。

方法 2：使用 Call Stack Window

在 HardFault_Handler 函数的 while(1) 处打调试断点，程序执行到断点处时点击“STOP”停止仿真。
在 Keil 菜单栏点击“View” -> “Call Stack Window”，弹出“Call Stack + Locals”对话框。
在对话框中右键选择“Show Caller Code”，跳转到出错之前的函数处，查看函数被调用或数组内存使用情况。

方法 3：修改 HardFault_Handler 函数

默认的HardFault_Handler处理方法不是B .这样的死循环么？楼主将它改成BX LR直接返回的形式。然后在这条语句打个断点，一旦在断点中停下来，说明出错了，然后再返回，就可以返回到出错的位置的下一条语句那儿

__asm void wait()
{
    BX lr
}

void HardFault_Handler(void)
{
    /* Go to infinite loop when Hard Fault exception occurs */
    wait();
}

在HardFault_Handler函数里加上一行软中断：__asm voalite (“BKPT #1”);打开编译器的CALL STACK，全速跑一下，如果进入了软中断，查看CALL STACK就知道是哪一个函数进入HardFault_Handler了。

总结

在遇到 HardFault 异常时，通过在断点处检查 LR 的值，可以分析程序状态。LR 在异常后通常为 0xFFFFFFFx，指示异常前的返回地址。根据 LR 的 ReturnStack 判断 PSP 或 MSP，找到栈顶获取返回地址，从而追溯到异常发生前的代码位置。在 MDK 中，利用 Memory 和 Disassembly Windows 可以辅助这一过程。

参考文章：
STM32关于我遇到的HardFault_Handler的处理
STM32硬件错误HardFault_Handler的处理方法
利用STM32的LR寄存器调试HardFault错误
Stm32 调试时发生HardFault_Handler

作者：吃货界的嵌入式攻城狮

物联沃分享整理
物联沃-IOTWORD物联网 » 【STM32程序调试与优化指南：解决数组越界与HardFault错误的全攻略】