恒美微站
首页
关于我们
建站服务
主题模板
案例展示
资讯中心
联系我们
关于STM32的HardFault_Handler、Error_Handler、assertFailed
首页
资讯中心
/
关于STM32的HardFault_Handler、Error_Handler、assertFailed
关于STM32的HardFault_Handler、Error_Handler、assertFailed
发布时间:2026/8/13 22:14:11
背景 两个批次PCBA烧录相同程序hex相同电路PCB新批次是在上一批次嘉立创返单下的我理解只有物料上的批次不一致因为STM32F4芯片的丝印明显不一样。现象上一批次正常。最新批次pcba程序不跑调试直接报硬Fault。哪怕断点打在main的开始一调试就报硬Fault不进断点。分析过程1、出现HardFault第一想到是上一个调用的函数是哪个即想确定触发HardFault的现场地点2、代码是O3优化断点打在main开始处一点调试断点没有停在main开始处直接报硬件Fault所以这种办法进行不下去。其实进HardFault后查看调用栈就可以知道之前运行了哪些函数以下是借助AI的过程AI定位是断言出错configASSERT先触发异常AI在断言处打断点不知道它是如何做到的我手工打不上程序先触发了断言的断点后面才是HardFault。我后面一系列询问想确定AI是基于怎么个想法最终定位到这个问题的。它大致的想法是1、程序出问题有很多出口如Error_Handler、assert断言、硬件Fault2、同时由于Error_Handler、assert断言这些地方出问题有可能后续代码的操作会导致硬件Fault。所以它监控这些出口。这些出口代表问题的原因有以下几大块1、HardFault表示cpu命令不对主要有数组越界参数类型不匹配等2、Error_HandlerHAL库初始化失败3、asserFailed纯程序逻辑即是否满足变量要求这个bkpt或许会触发硬件Fault。由于Error_Handler、assertFailed出现异常后后续的操作容易触发硬件Fault所以先排除是不是这些地方有问题。如果没有再从硬件Fault往上推调用关系如果有问题则在ErrorHandler和assertFailed更容易往上推出哪里调用导致出故障。调试时想确定是调用到哪里才触发的硬件Fault一、各自目的出处程序三种机制HardFault、Error_Handler、assert断言二、常见的触发原因三、三者之间联系四、出现异常后如何查看上一个调用的地方