01、问题背景
有一位客户反馈在STM32F207上使用CAN进行通信时会触发hardfault。
02、问题分析
STM32F207是比较老的芯片型号，早已过了市场的洗礼阶段。按开发人员的惯性思维，肯定是首先从软件开发的角度开始分析问题。既然是触发了hardfault，那么首先尝试读取下hardfault的上下文信息，特别是当触发hardfault中断时，代码正在运行的位置。好在客户的问题还是比较容易重现，于是得到下面的触发hardfault时的截图：
通过此截图可知，只知道是访问了数据地址0xB400 0000导致了总线错误。但是栈帧中保存的触发hardfault时代码的运行地址信息却又是不合理的。且在Call Stack中也看不出在hardfault触发时的运行地址(一般情况下可以看到)。
可知采用hardfault直接倒推的方法并不是每次都行，我们必须转换方法。
接下来我要客户将除了CAN通信之外的代码全部屏蔽，只留下CAN本身的通信，甚至对数据的处理也全部屏蔽。客户反馈这样操作后，测试结果仍然会出现hardfault。
为了确保客户执行到位，我基于ST的Demo板(STM3220G-EVAL评估板)写了一个CAN最小化测试工程，此板跟客户的实际硬件平台除了CAN收发器不同外，其它基本相同，甚至连HSE也都是25MHz。最小化测试工作在评估板上测试通过后，发给客户验证，结果客户反馈问题仍然存在。
相同的测试工程在ST官方的评估板上运行正常，但在客户的硬件环境运行不正常。这说明此问题跟软件关系不大，问题是出现在硬件方面。于是，接下来开始排查硬件。
在硬件方面跟hardfault最相关的就是内核电压是否稳定了，于是我要客户检查下VCAP引脚上的电压是否稳定，下面是客户发过来的波形截图：
从图中可知，内核电压有266mv的纹波，是不稳定的。与之对比，ST DEMO板运行起来后，VCAP上的纹波却挺干净：
从上图可知，内核电压为1.2V，纹波为13mv左右。这个是ST Demo板上的内核电压纹波。
由此可知，客户板子上的VCAP电压并不是稳定的，于是查看客户的原理图，两个VCAP引脚上是否如下图所示：
即MCU的两个VCAP引脚外部应该分别接一个2.2uF的低阻抗陶瓷电容。且需要尽可能靠近MCU。结果客户发现他们的板子上的这个电容容值有问题，更换后就一切恢复正常了。
03、小结
导致hardfault的原因有很多，很多客户的工程师在遇到这类问题时喜欢死磕代码。此文是一个很好的案例，在从代码的角度实在磕不动时，也要学会机动转向，从硬件的角度考虑下问题。
来源：STM32
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
