关于程序进入HardFault_Handle中断的问题分析

  • 前言:

毕业之后一直都有写技术类博客的想法,但是由于工作太繁忙了,所以一直就没有实施。趁着中秋佳节之际,完成自己的第一篇技术博客!写博客的原因有以下几点:一、感谢自己在工作中遇到困难的时候,能够在网上搜索到网友们写的技术博客帮助自己解决问题,希望自己的这篇博客也能帮助到其他人;二、本人认为知识应该是免费且共享的,将知识分享出来以供大家一起探讨,形成头脑风暴最后达到共同进步的目的;三、当作一个总结的作用,等哪天又碰到这类问题能够快速进行定性分析。

  • 问题描述

屏幕按键无效且卡住,过一会儿就好了,观察波形,初步怀疑是芯片在不断复位。

  • 问题分析

初步怀疑到芯片复位后,就去读取RCC_CSR寄存器的高十六位,发现确实独立看门狗复位标志被置”1”,进而分析有两种可能:一、看门狗时间太短,程序跑完需要的时间大于看门狗的时间从而来不及喂狗导致复位;二、程序跑死在某处了。对于第一种发现看门狗设置的时间是远远大于程序跑完的时间,从而排除,那么只能定位到第二种程序跑死。

  • 解决问题

现在的问题就是要找到程序死在哪里且解决掉这个程序BUG。通过观察代码,发现有几处while函数很值得怀疑,于是写了测试代码发现死在了硬件错误中断(HardFault_Handle)这里。在网上查找相关资料后发现大多数是说:数组越界或者堆栈溢出的问题。于是先在线仿真查看是执行哪条语句导致进入到HardFault_Handle(网上有很多方法去寻找这条语句,这就不列举了),找到后发现是与结构体成员判断语句有关,初步怀疑与地址没有四字节对齐有关,查看.MAP文件发现都对齐,应该不存在这样的问题。进一步查看汇编发现出问题的语句上一、二条都有PC指针进行偏移的操作,怀疑是这个指针进行偏移的时候出问题的,而PC指针指向的是Flash的地址,那么会不会是进行Flash读取出问题。再将底层的Flash以及时钟配置看了下,发现Flash的等待周期没有按照数据手册(如下图)进行正确配置。最后更正配置且进行测试,再无复现问题,就此解决。

关于程序进入HardFault_Handle中断的问题分析

  • 总结:

一、技术的成长道路类似游戏的打怪升级,所以在面对问题的时候不能害怕,应该具有解决了它又可以成长的正确想法且坚持下去,最后必会成为一名合格的工程师。

二、千万不能放过任何一个小问题,即使这个小问题在实验室出现的概率是百分之一,那么也应该用成千上万次的测试去复现;去解决掉它。因为在实验室出现的问题总有天也会在客户手中出现,到时候会给客户以及公司造成巨大的损失,所以在实验室不放过任何一个问题是对产品以及客户的负责。

三、世界上只有一种真正的英雄主义,那就是看清生活的真相之后,依然热爱生活!

 

上一篇:测试RT-Thread 动态模块


下一篇:GL_GL系列 - 会计科目管理分析(案例)(未完成)