两天前，我在调试一个 STM32 设备程序时，遇到了一个非常典型的中断陷阱，折腾了一整天才找到根源，今天把完整的分析和解决思路分享给大家。
一、项目功能背景
设备的硬件逻辑很简单：
- PF9：紧急停机按钮（按下立即切断设备输出，安全级最高，不做消抖处理）
- PF7：报警解除按钮（故障排除后，恢复正常运行）
软件设计思路：
本文不讨论安全逻辑是否合理，仅基于现有设计调试，聚焦遇到的 BUG。
二、BUG 现象：解除中断后立刻再次进中断
解除报警的核心代码如下：
if(CLEAR_ALARM_BUTTON == ON) // 解除按钮按下
{
alarm_flg = OFF; // 清除报警标记
__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_9); // 清除EXTI中断标志
HAL_NVIC_EnableIRQ(EXTI9_5_IRQn); // 重新使能中断
}
初看代码逻辑完全正常：清标志 → 开中断。但实际调试时：只要执行 HAL_NVIC_EnableIRQ ()，CPU 会立刻再次进入 EXTI 中断服务函数。
我最初排查方向：硬件干扰、软件逻辑错误、GPIO 配置问题…… 折腾了一整天，毫无进展。
最后静下心梳理 STM32 中断架构，才彻底找到问题根源。
三、关键知识点：STM32 中断的两层架构
这是解决问题的核心：STM32 中断分为完全独立的两层。
1. 外设层中断（厂商设计，以 EXTI 为例）
typedef struct
{
__IO uint32_t IMR; // 中断屏蔽寄存器（EXTI本地开关）
__IO uint32_t EMR; // 事件屏蔽寄存器
__IO uint32_t RTSR; // 上升沿触发
__IO uint32_t FTSR; // 下降沿触发
__IO uint32_t SWIER; // 软件触发
__IO uint32_t PR; // 中断挂起标志（必须手动清除）
} EXTI_TypeDef;
2. 内核层中断（ARM 公司设计：NVIC）
typedef struct
{
__IOM uint32_t ISER[8U]; // 中断使能寄存器
__IOM uint32_t ICER[8U]; // 中断失能寄存器
__IOM uint32_t ISPR[8U]; // 挂起标志置1
__IOM uint32_t ICPR[8U]; // 挂起标志清除
// … 其他寄存器
} NVIC_Type;
标准中断执行流程
—————————–内外分界———————————–
四、BUG 根源分析（重点！）
我的代码问题出在这里：
// 中断服务函数中
HAL_NVIC_DisableIRQ(EXTI9_5_IRQn);
关键结论：
HAL_NVIC_DisableIRQ () 只会关闭 NVIC 的中断响应（即NVIC内核中断使能位），不会清除内部挂起标志，也不会关闭 EXTI 外设！
完整故障链路：
这就是一开中断就立刻重入的根本原因！
五、最终解决方案
在重新使能中断之前，必须同时清除两个挂起标志：
修正后的安全代码：
if(CLEAR_ALARM_BUTTON == ON)
{
alarm_flg = OFF;
// 1. 清除EXTI外设中断标志
__HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_9);
// 2. 清除NVIC内核挂起标志（关键修复！）
HAL_NVIC_ClearPendingIRQ(EXTI9_5_IRQn);
// 3. 最后再开启中断
HAL_NVIC_EnableIRQ(EXTI9_5_IRQn);
}
加一行HAL_NVIC_ClearPendingIRQ，问题彻底解决。
六、核心总结（干货）
- EXTI：外设级，产生中断信号
- NVIC：内核级，响应中断信号
这个坑几乎每个 STM32 开发者都会遇到，理解了 EXTI+NVIC 的分层架构，以后遇到类似问题一眼就能定位。
