问题是由某客户提出的，发生在STM32F103VDT6芯片上。据该客户的工程师介绍，在其产品设计中，STM32的HSE外部连接了一个8MHz的晶体来产生振荡信号，然后通过STM32内部的PLL倍频到72MHz，作为STM32的系统时钟，以驱动芯片工作。此外，该产品外部连接了专用的看门狗芯片，用于监控STM32的运行状态。STM32内部的软件会在某个管脚上产生脉冲来复位看门狗。如果STM32未能及时产生脉冲以复位看门狗，那么看门狗会判断STM32的运行状态异常，并对其进行复位。

在对该产品进行可靠性测试时，特别进行了对看门狗监控时钟失效能力的测试。测试方法是将连接到HSE的晶体的两个端子接地，以停止晶体的振荡，从而验证看门狗是否能够对STM32进行复位。然而，试验结果显示，看门狗未能产生复位动作。进一步的测试揭示了，在失效情况下，STM32仍然向看门狗发送复位脉冲的情况。

调研：

重复测试，确认其所述现象属实。检查软件代码，确认其软件没有开启 STM32 的 CSS功能。修改代码，将 PLL 的二分频从 STM32 的 MCO 管脚送出，以方便用示波器观察。

通过控制晶体的管脚是否接地来控制 HSE 是否振荡。当 HSE 正常振荡时，MCO 送出的信号频率为 36MHz，当 HSE 停止振荡时，MCO 送出的信号的频率在 1.7MHz 附近，如图（一）所示:

通过调试器观察寄存器 RCC_CFGR 中的 SWS 控制控制位，其值为[10]，说明此时的系统时钟确实来自 PLL 的输出。

从 STM32F103VD 的数据手册中查找 PLL 相关的参数如表（一）：

其中，PLL 的输出频率范围是 16MHz – 72MHz。也就是说，PLL 在处于相位锁定的状态下，可以输出 16MHz – 72MHz 的时钟信号。

而当输入信号频率过低而导致输出信号频率低于 16MHz 时，将可能处于失锁的状态。在这状态下，它的输出信号的频率与输入信号的频率之间，不一定符合所设定的倍频与分频关系。更确切的说，不能通过公式:

得出“输入信号频率为零时，输出信号频率也为零”这样的结论。这一点与实测的结果相吻合。

结论：

STM32 的 PLL 在没有输入信号的情况下，仍能维持在最低的频点处振荡，产生输出。以至，CPU 及其它外设仍能在 PLL 送出的时钟的驱动下运行。所以，通过判断有无时钟来驱动 CPU 执行指令的方式来判断 HSE 是否失效是行不通的。

处理：

对软件做如下修改：

\1. 在软件的初始化部分，开启 STM32 的 CSS 功能；

\2. 修改 NMI 中断服务程序，加入 while(1) 陷阱语句；

开启 CSS 功能后，当 HSE 失效时，STM32 会自动开启 HSI，并将系统时钟的来源切换到HSI 的输出，同时产生 NMI 中断。这样，程序的流程将停留在 NMI 中而不能产生复位片外的看门狗的脉冲。当片外看门狗溢出后，就会复位 STM32，使其恢复到正常驻的状。

建议：

STM32 中的 CSS 功能是专门为检测和处理 HSE 失效而设计的。但该功能在 STM32 复位后是被禁止的，需要软件对其使能才会发挥作用。

当 CSS 单元检测到 HSE 失效时，它会使能 HSI,并将系统时钟切换到 HSI。同时，它会关闭 HSE，如果 PLL 的输入信号来自 HSE的输出，它也会关闭 PLL。

CSS 单元在做时钟调整的同时，也会产生一个 NMI 中断请求，和一个送给高级定时器的刹车信号。NMI 中断请求会产生一个 NMI 中断，以便用户程序可以在中断服务程序中做紧急处理，而刹车信号则是使高级定时器进入刹车状态，以防止由其控制的电机驱动桥臂由于失去控制而过流。

用户程序可以在 NMI 中断服务程序中尝试恢复 HSE 及 PLL 的功能，也可以使用陷阱让程序的流程停留在服务程序中，从而等待看门狗复位整个系统。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！