基于TIMER3发生捕获中断丢失问题分析与总结

前言

在一洗衣机MC项目中，客户选择使用STM32F030作为主控芯片。使用TIMER3(CH3)来捕获电机的HALL Sensor的中断，同时使用TIMER3（CH2）的OC功能，在OC match中断中调整转速。客户在调试中发现，当捕获中断和OC中断“同时发生（对齐）”时，会发生捕获中断丢失。

问题分析

客户最初发现使用该配置控制电机时，在某一时刻会出现电机转速异常。经过抓取波形发现，HALL Sensor和捕获输出波形（在中断中翻转IO）不匹配，在某个时刻，会出现“中断丢失”现象，表现为捕获输出高电平或低电平周期被拉长，如图1所示。黄色为HALL信号，绿色为捕获中断输出，紫色为OC中断输出，可以明显看到在第四个上升沿之后，高电平长度被拉长半个周期。客户怀疑是硬件Bug导致中断“同时发生”时，捕获“中断丢失”，从而导致该问题。

图 一

查看Erratasheet， 没有相关的描述。另外，硬件BUG导致中断丢失的可能性较小，因为中断同时发生的概率很低而该现象很容易复现。

构建测试环境

通过CubeMx构建对应的测试工程，分别在捕获和OC中断中翻转IO来检测中断状况。另外，通过其它开发板产生相应的PWM来模拟HALL信号。经过测试发现，使用Cube库生成的代码，并没有“丢失中断”的现象，波形见下图。

代码分析

客户的代码，包括中断服务函数都是通过直接操作寄存器的方式编写。分析客户的代码发现，客户在中断服务函数中清除相关中断标志位时是通过常用的寄存器操作方式“读-修改-写”来完成，如下：

TIM3->SR&= ~TIM_SR_CC3IF; /* Clear the flags */

而在HAL Driver中是通过对应的位直接赋值的方式清除，如下：

#define__HAL_TIM_CLEAR_IT(__HANDLE__, __INTERRUPT__) ((__HANDLE__)->Instance->SR= ~(__INTERRUPT__))

结合客户观察到的现象，怀疑可能的原因是捕获中断标志在从读状态寄存器到写入寄存器之间被置位，这样的话，该标志就可能未被检测处理到就被清除掉了，从而导致异常的发生。

将HAL Driver函数中的中断服务函数修改成与客户一样的“读-修改-写”方式来清除对应标志位，该问题被复现。

小结

如果通过直接操作寄存器的方式来集成底层驱动，那么在通过“读-修改-写”方式操作此类会由硬件修改的寄存器时，一定要加倍小心。根据寄存器具体的描述，可以采用直接写入或者联合体（按位修改）的方式修改。