单片机STM32死机问题分析及解决方案总结

1、程序卡死在非中断的程序中,含有for while等循环体函数参数不正确导致,例如memcpy CRCcheck等。
现象:程序主逻辑无法执行,但是各个中断服务程序能够正常运行。
解决方法:
1)在中断程序中点灯或者打印,判断中断程序是否能够正常运行;
2)keil的debug模式在线调试运行,即可知道程序卡死位置。
3)在2)无法满足时,在程序主逻辑中打印或者点灯,多次编译烧录,判断卡死位置。

2、程序卡死在中断中,中断程序中没有清除中断标志位,或者中断服务程序的触发频率太高,中断没有执行完毕又触发了中断标志位,单片机在循环执行中断服务程序。
例如在高频率的中断服务程序中增加printf打印信息容易造成该现象。
现象:程序主逻辑无法执行,部分中断程序也无法执行。
解决方法:
1)在问题发生时,调整没有执行的中断程序的优先级为最高优先级,例如SysTick中断优先级、TIMER有限级等,在该对应中断服务程序中点灯或者低频定时打印,观察是否执行。
2)如果执行,则说明肯定卡死在中断中,仔细检查所有的中断程序。仍无法判断问题点,则逐步降低调整优先级的中断服务程序,直到其不被执行,确定问题程序优先级,缩小范围,再找问题。

3、程序进入HardFault,HardFault本身也是一个中断,只不过其中断优先级为-1,高于一切用户可设置中断。
产生原因(常见的均为地址类问题):
1)访问了单片机无法到达的地址;
2)访问地址不对齐,尤其是在*(int *) *(float *)等多字节强制取值时容易出现,检测强制取值的地址是否为四字节对齐。
3)PC指针跑飞,该现象在我多年经验中只遇到过一次,是在强干扰情况下,芯片PC指针突然变为非常异常值,芯片直接进入HardFault。该情况实际很少遇到,通常情况下芯片不会无缘无故跑飞,多数都为自身程序问题。
解决办法(出现问题后只能断电重启,但可以找出造成问题的点):
1)代码中增加HardFault中断服务程序,在中断向量表中可以找函数名称。
2)服务程序中增加特殊的点灯提示即可。后期任何进入HardFault的问题都能一目了然。
3)HardFault中断服务程序中可以保存芯片信息到Flash中,以便重新上电时检查问题点,保存的信息主要是进入HardFault前的PC指针,通过在该PC指针在.map文件中查找对应区间的函数,即可确认是什么函数造成了HardFault。该操作的详细步骤自行百度。

4、芯片不停的高频重启(此处不讨论硬件造成的问题),不是所有的地址异常等都会进入HardFault,有些是造成芯片重启。
现象:
1)看上去芯片主程序、中断程序、HardFault 什么都不执行了。
解决方法:
1)在main()函数的最开始(注意要先配置外设),增加点灯和延时处理,或打印。观察上电后是否有输出。并且反复输出,或者灯闪烁。
2)逐步调整点灯位置,确认造成死机点。
3)在程序执行到main之前,是先执行芯片的RESET中断服务程序,这之间会初始化中断向量表,初始化堆栈等,在.s文件中有相应的汇编代码。如果死在main之前,可尝试在RESET中断服务程序中直接操作寄存器,配置时钟和GPIO外设,控制点灯,观察是否能够点亮,以确认问题。

5、其他,芯片主时钟未开启、时钟晶振配置与实际晶振器件不服,等等等等等等等等等等等等等等等等都可能造成死机。
解决方法:
1)熟读STM32用户手册;
2)熟读《CotexM3权威指南 》 或者 《CotexM3 M4权威指南》
3)祈祷,自求多福!

  • 3
    点赞
  • 40
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: STM32 死机(也称为硬件故障)是指STM32单片机在运行过程中出现了无法恢复的错误,并导致程序停止响应或崩溃的情况。硬件故障是由于程序运行时发生了非法指令、存储器读写错误、中断异常等原因引起的。 对于STM32硬件故障的分析,可以通过以下步骤来进行: 1. 异常向量表(NVIC)定位:硬件故障会导致程序跳转到异常处理器,通过查看异常向量表可以确定具体是哪个异常处理器被触发。 2. 寄存器值分析:查看产生硬件故障时相关寄存器的值,如程序计数器(PC)、堆栈指针(SP)等。这些值可以提供更多关于故障发生时的程序状态的信息。 3. 中断日志分析:如果硬件故障是由于中断异常引起的,可以通过打印中断日志来获取更多信息。中断日志包括中断号、中断源、中断服务例程等。 4. 调试工具使用:使用STM32开发板上的调试工具(如J-Link、ST-Link等)进行调试,可以通过断点、查看寄存器、查看存储器等功能,进一步分析硬件故障。 5. 代码回溯:通过查看产生硬件故障之前执行的代码,可以确定是否存在编程错误或者不合法操作,如访问空指针、溢出问题等。 在分析完硬件故障后,可以根据具体情况采取相应措施来修复问题。常见的修复措施包括修改代码错误、检查硬件连接、更新驱动程序等。同时,也推荐在开发过程中使用断言(assert)功能,及时捕获并处理潜在的硬件故障。 ### 回答2: STM32死机HardFault通常是由于程序错误或硬件故障引起的。下面是对STM32死机HardFault进行分析的常见步骤: 1. 排查硬件问题:确保硬件电源和时钟正常工作,并检查是否存在短路或其他硬件故障,例如引脚连接错误等。 2. 检查编程错误:查看代码中是否有潜在的错误,例如没有初始化变量、数组越界、栈溢出等。使用调试工具(例如GDB)可以更方便地检测程序中的错误。 3. 检查中断问题:HardFault中断可能是由于异常中断导致的。检查中断的优先级设置和中断服务程序是否正确。 4. 查看硬件异常:使用STM32芯片自带的硬件调试模块(例如Cortex-M3的Fault Status Register)可以查看硬件异常的状态。这些状态信息可以提供有关错误原因的线索。 5. 查看堆栈信息:查看堆栈的状态可以帮助我们了解在死机时程序执行的位置。这些信息可以通过调试工具或在程序中添加日志输出来获得。 6. 运行时错误检测:在程序中使用合适的错误检测方法,例如检测指针是否为空、检测函数返回值等,可以帮助我们在错误发生时及时发现问题。 7. 固件更新:如果已确定硬件问题和代码错误都不存在,则可能是芯片固件本身的问题。在这种情况下,更新芯片固件可能是解决问题的方法。 以上是对STM32死机HardFault进行分析的常见步骤,可以根据具体情况进行适当的调整。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值