HardFault_Handler分析
今天用合泰的M0进入了HardFault_Handler查了下资料,总结下。
以下是我从高手那抄的:
在用Keil对STM32的程序进行仿真时程序有时会跑飞,停止仿真程序会停在HardFault_Handler函数里的死循环while(1)中。这说明STM32出现了硬件错误。
文章图片
STM32出现硬件错误可能有以下原因:
(1)数组越界操作;
(2)内存溢出,访问越界;
(3)堆栈溢出,程序跑飞;
(4)中断处理错误;
遇到这种情况,可以通过以下2种方式来定位到出错代码段。
方法1:
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进行搜索,然后就会找到相对应的代码。这里的代码就是进入循环中断之前的情况。仔细查看附近区域的相关代码来排查错误具体原因。
文章图片
方法2:
2.1在硬件中断函数HardFault_Handler里的while(1)处打调试断点,程序执行到断点处时点击“STOP”停止仿真。
【HardFault_Handler分析】
文章图片
2.2 在Keil菜单栏点击“View”——“Call Stack Window”弹出“Call Stack + Locals”对话框。然后在对话框中右键选择“Show Caller Code”,就会跳转到出错之前的函数处,仔细查看这部分函数被调用或者数组内存使用情况。
利用上面方法定位到了出错点,结果发现是数组对齐的问题,定义了8K的数组,const unsigned char BC76XX[BC76XX_170827A5_SIZE] =,
#define _RF_PARAMETER_PTR_(BC76XX+ 0x0100)
patch_index = (u8 *)_RF_PARAMETER_PTR_;
if(((RF_PARAM_DATA *)patch_index)->valid_falg == 0xAA55A55A)//运行这句有问题进入hardfault
分析发现patch_index地址是0x3C46,而(RF_PARAM_DATA *)patch_index)->valid_falg是u32,字节没有4字节,0x3C46不能整除4,于是__align(4) const unsigned char BC76XX[BC76XX_170827A5_SIZE] =这样就行了,运行发现patch_index的值变为ox3C48了,4字节对齐。
推荐阅读
- 如何寻找情感问答App的分析切入点
- D13|D13 张贇 Banner分析
- 自媒体形势分析
- 2020-12(完成事项)
- Android事件传递源码分析
- Python数据分析(一)(Matplotlib使用)
- 泽宇读书会——如何阅读一本书笔记
- Java内存泄漏分析系列之二(jstack生成的Thread|Java内存泄漏分析系列之二:jstack生成的Thread Dump日志结构解析)
- ffmpeg源码分析01(结构体)
- 关于两种潜能生的性格分析