关于STM32的HardFault_Handler、Error_Handler、assertFailed
背景 ：两个批次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断言、硬件Fault；
2、同时由于Error_Handler、assert断言这些地方出问题，有可能（后续代码的操作）会导致硬件Fault。
所以它监控这些出口。这些出口代表问题的原因有以下几大块：
1、HardFault：表示cpu命令不对，主要有数组越界，参数类型不匹配等；
2、Error_Handler：HAL库，初始化失败；
3、asserFailed：纯程序逻辑，即是否满足变量要求；
这个bkpt或许会触发硬件Fault。
由于Error_Handler、assertFailed出现异常后，后续的操作容易触发硬件Fault，所以先排除是不是这些地方有问题。如果没有，再从硬件Fault往上推调用关系，如果有问题：则在ErrorHandler和assertFailed更容易往上推出哪里调用导致出故障。
调试时想确定是调用到哪里才触发的硬件Fault