数组越界

在项目开发过程中，配置串口外设是一个常见的任务，但在实际操作中，我们可能会遇到一些预料之外的问题。例如，在调试过程中，我们发现单片机只接受了一次数据后便不再接收，这无疑是一个棘手的问题。通过进一步的调试，我们发现程序在接收了第一个数据后卡在void HardFault_Handler(void)函数。
后面发现在主程序while屏蔽掉这个函数就没有出现，由于当时我们还没有使用到这个函数，因此决定暂时屏蔽它，以观察是否还有其他问题出现。

然而，这种做法仅仅是暂时缓解了问题，并没有从根本上解决问题。事实上，问题的根源在于我们程序中的一个分函数，即函数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错误

1.1在硬件中断函数HardFault_Handler里的while(1)处打调试断点，程序执行到断点处时点击“STOP”停止仿真。

1.2 在Keil菜单栏点击“View”——“Registers Window”，在寄存器查看窗口查找R14(LR)的值。如果R14(LR) = 0xFFFFFFE9，继续查看MSP（主堆栈指针）的值，如果R14(LR) = 0xFFFFFFFD，继续查看PSP（进程栈指针）的值。我的程序R14(LR) = 0xFFFFFFF9，接下来以此为例。

1.3 在Keil菜单栏点击“View”——“Memory Windows”——“Memory1”，在“Address”地址栏中输入MSP的值：0x20001288，然后在对应的行里找到地址。地址一般以0x08开头的32位数。本例中，地址为0x08003CB9。

1.4 在Keil菜单栏点击“View”——“Disassembly Window”，在“Disassembly”窗口中右击，在下拉菜单中选择“Show Disassemblyat Address…”。在弹出框“Show Code atAdress”的地址框中输入地址0x08003CB9进行搜索，然后就会找到相对应的代码。这里的代码就是进入循环中断之前的情况。仔细查看附近区域的相关代码来排查错误具体原因。

举例：

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

2.1在硬件中断函数HardFault_Handler里的while(1)处打调试断点，程序执行到断点处时点击“STOP”停止仿真。

2.2 在Keil菜单栏点击“View”——“Call Stack Window”弹出“Call Stack + Locals”对话框。然后在对话框中右键选择“Show Caller Code”，就会跳转到出错之前的函数处，仔细查看这部分函数被调用或者数组内存使用情况。

方法3

默认的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了。

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