问题描述
在使用基于 ARM CORTEX-M3、M4 或 M7 系列的 STM32 芯片做产品开发时,可能有人遇到过单次事件会触发两次中断的情形。或许对异常现象的表述不尽相同,比方有的人会说怎么中断请求标志要清 2 次才行;由于中断里有些执行操作,有人会说代码里明明只执行一次,可实际运行时却是两次;有的人会说,有些执行动作放在中断外执行正常,放到中断服务程序里又异常了等等。记得有一次,有个 STM32 用户反映,他的 SPI 实际发送效果跟程序代码里设计的完全不一样,明明是 8 位发送,硬生生变成了 16 位发送,诡异的很。诸如此类。
问题分析
像上面提到的这些情况,他们的中断服务程序代码都有个共性。那就是他们把清外设中断请求标志的那行代码放在中断程序的结尾处。
问题验证
其实,当执行完那句清标志的代码后,按理 CPU 该做出栈操作了。但是,由于此时硬件检测到刚才没有实际清零的有效中断请求标志,立即做出了一个决定----不做出栈操作,而是马上准备响应该中断请求。这就是 ARM 为 Cortex-M 内核中断设计的咬尾机制。新的中断响应基于刚完成的中断服务程序不做压栈只稍作准备后立即运行新的中断服务程序,当然这里的“新”理解为新的一次比较合适。说到这里,既然决定不做出栈操作了,至于出栈所需时间是多少个 CLK已经不重要了。
问题小结
这里基于多个客户共性话题,由浅入深地做了相应分析和释疑。抛砖引玉地就 ARMCortex-M4 内核的咬尾中断机制做了相关介绍,并基于具体测试代码做了些直观的体验。希望能对大家在未来的 STM32 应用开发有所帮助。