关于程序进入HardFault_Handle中断的问题分析
作者：互联网
- 前言:
毕业之后一直都有写技术类博客的想法，但是由于工作太繁忙了，所以一直就没有实施。趁着中秋佳节之际，完成自己的第一篇技术博客！写博客的原因有以下几点：一、感谢自己在工作中遇到困难的时候，能够在网上搜索到网友们写的技术博客帮助自己解决问题，希望自己的这篇博客也能帮助到其他人；二、本人认为知识应该是免费且共享的，将知识分享出来以供大家一起探讨，形成头脑风暴最后达到共同进步的目的；三、当作一个总结的作用，等哪天又碰到这类问题能够快速进行定性分析。
- 问题描述
屏幕按键无效且卡住，过一会儿就好了，观察波形，初步怀疑是芯片在不断复位。
- 问题分析
初步怀疑到芯片复位后，就去读取RCC_CSR寄存器的高十六位，发现确实独立看门狗复位标志被置”1”，进而分析有两种可能：一、看门狗时间太短，程序跑完需要的时间大于看门狗的时间从而来不及喂狗导致复位；二、程序跑死在某处了。对于第一种发现看门狗设置的时间是远远大于程序跑完的时间，从而排除，那么只能定位到第二种程序跑死。
- 解决问题
现在的问题就是要找到程序死在哪里且解决掉这个程序BUG。通过观察代码，发现有几处while函数很值得怀疑，于是写了测试代码发现死在了硬件错误中断(HardFault_Handle)这里。在网上查找相关资料后发现大多数是说：数组越界或者堆栈溢出的问题。于是先在线仿真查看是执行哪条语句导致进入到HardFault_Handle（网上有很多方法去寻找这条语句，这就不列举了），找到后发现是与结构体成员判断语句有关，初步怀疑与地址没有四字节对齐有关，查看.MAP文件发现都对齐，应该不存在这样的问题。进一步查看汇编发现出问题的语句上一、二条都有PC指针进行偏移的操作，怀疑是这个指针进行偏移的时候出问题的，而PC指针指向的是Flash的地址，那么会不会是进行Flash读取出问题。再将底层的Flash以及时钟配置看了下，发现Flash的等待周期没有按照数据手册（如下图）进行正确配置。最后更正配置且进行测试，再无复现问题，就此解决。
- 总结：
一、技术的成长道路类似游戏的打怪升级，所以在面对问题的时候不能害怕，应该具有解决了它又可以成长的正确想法且坚持下去，最后必会成为一名合格的工程师。
二、千万不能放过任何一个小问题，即使这个小问题在实验室出现的概率是百分之一，那么也应该用成千上万次的测试去复现；去解决掉它。因为在实验室出现的问题总有天也会在客户手中出现，到时候会给客户以及公司造成巨大的损失，所以在实验室不放过任何一个问题是对产品以及客户的负责。
三、世界上只有一种真正的英雄主义，那就是看清生活的真相之后，依然热爱生活！
标签：发现,Handle,中断,Flash,程序,博客,看门狗,问题,HardFault 来源： https://blog.csdn.net/weixin_43313573/article/details/120383161