问题：
0 {4 ?9 E" K& \8 c某客户工程师在某型号新产品的设计中，使用了 STM32F103XXT6。据其工程师讲述：他们在设计中，使用了一个外部中断，用来检测某事件的发生，从而唤醒低功耗模式下的 STM32。对应于该中断输入，有一中断服务程序，内容如表（一）所示。在实测中发现偶尔会发生在有该外部中断输入时 STM32 并未回到正常的运行状态的情况。测量此时 STM32 的功耗，发现其功耗明显增大，说明已从低功耗唤醒。使用调试工具调试，发现当出现该现象时，程序停留在表（一）所示的中断服务程序中，不能退出。进一步跟踪，发现“行（1）”的判断不能通过。进入函数 EXTI_GetITStatus 进一步检查，发现该函数如表（二）。继续跟踪，发现“行（2）”的判断不能通过，而原因是上一行中的 EXTI->IMR&EXTI_Line 值为‘0’，也就是该中断使能位没有被打开。讲述至此，其工程师一再重复着一句话“为什么中断使能位关闭了，还能进入中断服务程序…”。再三安慰不能使其平静，或许他真的崩溃了。
& K  O) i% d! H3 c
. _$ k1 q0 {5 n- u
: v0 W; J5 b% f$ R
1 U- x8 y8 L- u
% v  D+ y( `4 @
, g/ M. `3 m% Q1 b调研：
天行有常，不为尧存，不为桀亡。我坚信这一点，所以我没有崩溃。检查其代码，找到了“行（3）”，相信是该行代码关掉了中断使能位。于是，建议其工程师修改代码：
1. 将“行（1）”改为：if(EXTI_GetFlagStatus(IO_PIN_CHUCK) != RESET)；
2. 在“行（3）”后插入语句：EXTI_ClearITPendingBit(IO_PIN_CHUCK) ；
   如表（三）所示：



修改后重新测试，其工程师反馈结果说：问题解决了，但依然不能理解，为什么这样改动会带来结果的不同。之后就是不断重复的“为什么…为什么…”，仍在崩溃中…

) B8 q: \1 [! L# v" f结论：
至此，该下个结论了。其中断服务程序中有两处错误：
1. 选错了中断标志判定方法，应该检测中断请求位，而不能检测中断使能位；
8 @1 f2 N3 m) k, O# N2. 在屏蔽中断后，应该再次清除中断请求位，而其代码中没有。
. O, ^. j6 }# Q
( k/ q& o0 S* Y( z$ |' l8 [' p第 1 点错误会导致对中断产生原因的判断失效，而第 2 点错误则导致缺少对管脚上信号抖动的预防能力。当外部中断的输入信号上有抖动时，STM32 会收到一连串的信号跳变，造成已清除的中断请求位被重新置起。在退出中断服务程序之后，由于中断请求仍在，所以会重新进入中断服务程序。而此时中断使能位已被清除，导致“行（1）”的判断不成立，从而中断服务程序不会对中断请求位做任何的处理，使得中断请求得以保留，最终发生中断服务程序无休止的重复进入的现象。
   
处理：
修改代码，如表（三）。
   
8 c. f1 E5 J# A2 C9 Y2 K. N; {建议：
( y& ^0 i$ q  Q7 }! @: `对于 STM32 来说，除了由于外设的中断请求位没有清除之外，还有另外一种原因，也能导致重复进入中断服务程序。STM32 属于多时钟域系统，外设的信号到达 CPU 会有几个时钟节拍的延迟，造成外设撤消中断请求动作也会有延迟。如果中断服务程序过快的退出，而此时撤消中断请求的动作尚未被CPU 认可，就会出现重入中断服务程序的现象。
- [* \! o1 k0 U. x1 D- N  p4 d   
+ t$ e! {9 U' X; s7 i对于这一现象，如果应用程序处理不当，也会导致错误。通常，我们可以通过判断外设的中断请求标志，来避免中断的重复处理。所以，在中断服务程序中，要做的第一件事就是检测中断请求标志，如果没有，则直接返回。这样，既便“中断服务程序重复进入”发生，也只是在中断服务程序中“空转一圈”，不会产生实质的后果。当然，在中断服务程序中要做的第二件事，就是清除该标志，不然，中断服务程序就不是“转一圈”或“转几圈”，而是“无穷多圈”。有时，在程序设计中，希望对中断的管理操作立即生效，而不能延后。这时，可以使用 CPU 对中断的管理机制，而不是通过对外设的操作来实现。比如，CPU 具有对全体中断或某个中断的使能控制，是即时生效的，因为整个 CPU 处于同一个时钟域。