刚拿到这块开发板的时候，我以为“点灯”和“读按键”这种入门操作不会有任何惊喜。结果把 B1 按钮接到外部中断上一试，板子简直像被按住不放一样：按下一次，中断疯狂触发，串口刷屏、LED 状态乱跳，甚至上电什么都不按它就开始自己跑中断。查了半天，问题不是一个点，而是一串点叠加在一起。这篇内容就围绕 Nucleo-F746ZGT 的按钮中断“总是触发（always fires）”这个问题，把从硬件到软件、从配置到消抖的完整排查路径写清楚。如果你现在也卡在同一个现象上，这篇文章能帮你少走不少弯路。
1. 问题现象与“总触发”的三种典型表现
“中断 always fires”在不同人嘴里可能指完全不同的现象。先把现象定义清楚，排查方向才能定下来。我在这个项目里前后复现了三类典型情况，它们的根因基本不重叠。
1.1 按下一次，中断却像“连发”一样连续进入
第一种现象最经典：B1 按一下，中断服务函数被触发了好几次，次数还不太固定。有时候 2 次，有时候 5 次，串口打印出来的尖峰时间间隔大概在几毫秒到十几毫秒之间。最初我以为是按键接触不良，后来用手指按住不松，中断依然偶尔自己冒出来。
这个问题基本指向两个方向：一是机械开关的抖动，每个抖动沿都被当成有效事件；二是 GPIO 浮空输入，引脚电平在悬空区间漂移，产生大量随机边沿。如果只是抖动，用示波器看一眼就能确认，波形会在高电平和低电平之间来回弹跳几十次。
1.2 上电就触发，按钮连碰都没碰
第二种现象更让人崩溃：程序一烧进去，甚至还在复位阶段，中断就开始触发。这时候按钮根本没人碰，但 PC13 的电平状态已经让 EXTI 认为“边沿来了”。
这种通常不是抖动问题，而是 GPIO 的上下拉配置和按钮电路的电平常态不匹配。比如你的按钮在未按下时应该保持高电平，但你可能把引脚配置成了下拉；反过来，按钮常态为低电平的时候，你配置了上拉或者干脆不配置上下拉，引脚浮空，干扰信号就会直接串进 EXTI 检测器。
1.3 调试器一停，一切都正常；全速跑起来，问题就复现
还有个特别隐蔽的情况：在中断服务函数里打上断点，单步执行时一切正常，按钮按多少次进多少次；但全速运行就疯狂触发。这种一般不是误触发，而是中断服务函数处理太重。CPU 在 ISR 里花了几十毫秒处理事情，按键状态又在该期间内抖动多次，退出 ISR 的瞬间新的边沿已经挂起，于是又进一次，看起来就像“永远在触发”。
上面的现象可以归纳成一张排查方向表，后面每一节都会对应展开。
| 现象 | 最可能的方向 | 优先级 |
|---|---|---|
| 按下一次进入多次 | 抖动、边沿配置、浮动电平 | 高 |
| 上电就触发、没人按也进 | 上下拉配置、常态电平不匹配 | 高 |
| 全速复现、断点消失 | ISR 过重、新边沿挂起 | 中 |
| 状态随机、时好时坏 | 浮空输入、外部干扰 | 中 |
2. PC13 这条中断线上到底发生了什么
要理解按钮中断为什么会“乱触发”，得先把 Nucleo-F746ZGT 上从按钮到 CPU 的整条链路在脑子里过一遍。这板子的用户按钮叫 B1，连接的是 PC13。PC13 并不像 PA0、PA1 那样每个引脚都单独占用一条 EXTI 中断线，它挂在 EXTI15_10 这条共享线上，也就是说引脚 10 到 15 的中断都汇入同一个外部中断服务函数EXTI15_10_IRQHandler。很多人第一次在这一步就蒙了，明明用的是 PC13，中断函数名字里却写着一串 15_10。
2.1 先看清 B1 的电路方向：按下到底拉高还是拉低
很多人写代码前没有做这一步，直接把网上抄的 “GPIO_PIN_RESET” 当标准答案，结果就栽了。Nucleo-F746ZG 常见的 MB1136 原理图里，B1 按钮一端连接 PC13，另一端连接 GND，也就是说按下瞬间 PC13 会被拉到低电平，这是一种低电平有效的接法。
但这并不是所有 Nucleo 版本都一样的，个别板子 B1 按下接的是 VDD。拿到手第一件事应该打开板子的原理图确认一下，别凭经验猜。如果按下是低电平，内部电阻要配置成上拉，才能保证常态是高；反过来按下是高电平，就需要下拉电阻。
2.2 GPIO、AF、EXTI、NVIC：四级链路一个都不能错
按键按钮要触发中断，信号链路从外到内是：引脚电平变化 -> GPIO 模块的 EXTI 检测器 -> EXTI 控制器置位挂起寄存器 -> NVIC 判断优先级后进入EXTI15_10_IRQHandler。
其中一个很容易被忽略的点是：STM32F746ZGT 的 GPIO 输入模式本身没有内部滤波，所有毛刺都会直接送到 EXTI 检测器。PC13 上的高电平持续时间只要超过检测器的建立时间，一个下降沿就会被记录。所以后面做软件消抖不是“可选优化”，而是“必须措施”。
2.3 HAL 库在每次中断里帮你做了什么
如果你使用的是 STM32CubeMX 自动生成的代码，EXTI15_10_IRQHandler默认会调用HAL_GPIO_EXTI_IRQHandler(GPIO_Pin)。这个函数内部的核心逻辑是判断EXTI->PR挂起寄存器中对应位是否为 1，如果是 1，就向EXTI->PR写入 1 来清除挂起位，然后调用回调函数HAL_GPIO_EXTI_Callback。
也就是说，清除中断标志这一步 HAL 库已经帮你做了。如果你在回调里又把同一个事件触发到自己的业务函数中，或者你手动重写了 ISR 但漏掉了挂起位清除，就会发生“执行完中断后，退出时旧挂起状态还在，立刻再次进入”的经典问题。
3. 五个最常见的根因：为什么中断会“always fires”
下面这五个根因是我反复验证后整理出来的，任何一个都足以让按键中断看起来像“发疯”。你可能只中了一个，也可能像我当时一样，好几个问题叠在一起。
3.1 浮空输入：最隐蔽的元凶
GPIO 的上下拉配置错，带来的问题不是“按键无效”，而是“按键疯狂误触发”。因为引脚在按键释放时并没有被驱动到一个确定电平，外部干扰、手指靠近、电源纹波都有可能让引脚电压在阈值附近来回穿越。
以 PC13 低电平有效为例，正确做法是Pull = GPIO_PULLUP。如果配置成了GPIO_NOPULL，PC13 在按钮释放时是悬空的。尤其在板子放在桌面上、旁边有开关电源或手靠近时，误触发概率会非常大。这类问题在实验室里用示波器探头搭上去时往往“看起来正常”，因为探头本身的阻抗改变了引脚状态，顺手把干扰治好了，等你撤掉探头，问题又回来了。
3.2 触发电平配置成双边沿，按一下当然出两下
GPIO 的 EXTI 触发模式有三种：上升沿、下降沿、双边沿。很多人图省事，直接配成GPIO_MODE_IT_RISING_FALLING，认为“不管按下还是释放都能检测到，稳赚不亏”。实际上这个配置适合旋转编码器那种需要同时检测两个方向信号的场景，普通按钮用双边沿，按下时一个下降沿，释放时一个上升沿，一次按压就产生两次中断事件。
如果你的业务逻辑里只有一个按下计数器，这种配置会让计数结果翻倍，看起来就像是“一次按下，中断触发了多次”。
3.3 中断标志不清除，退出立刻再进来
HAL 库自动清标志给大多数人提供了便利，但同时也让人忽略了 “EXTI 挂起位必须清除” 这个底层机制。如果你是自己写的寄存器版本：
void EXTI15_10_IRQHandler(void) { if (EXTI->PR & EXTI_PR_PR13) { // 忘记写 EXTI->PR = EXTI_PR_PR13; button_flag = 1; } }那么 EXTI 的挂起位会一直保持置 1，中断退出后 NVIC 立刻再次响应该中断，形成“永远触发”的死循环。判断这个问题的办法很简单：在中断函数入口加一个 GPIO 翻转，用逻辑分析仪看翻转波形间距。如果间距极短且完全相等，多半就是挂起位没清。
3.4 在 ISR 里干重活，退出瞬间又被新边沿唤醒
STM32F746ZGT 的主频有 216 MHz，跑一个 GPIO 翻转不过是几个时钟周期的事，但如果你在中断回调里做了HAL_Delay()、串口阻塞发送、复杂的浮点计算，整个中断执行时间可能被拉长到几十毫秒。机械按键从按下到稳定大约需要 5 到 20 毫秒，在这段时间内会产生多次抖动。
如果 ISR 里面正好在做耗时操作，按键还在抖，退出中断的瞬间新的下降沿又被捕捉到，于是又进一次。这个模式看起来像是“中断一直在触发”，实际是“ISR 的每次执行都覆盖了一次完整的按键抖动过程”。
3.5 机械抖动：每一个抖动沿都被当成有效事件
机械开关的抖动是物理现象，不是软件 bug。按下瞬间，簧片接触、反弹、再接触，电平会在几毫秒到十几毫秒内快速跳变。示波器上能看到一串毛刺，每个毛刺都包含下降沿和上升沿。如果你的 EXTI 是下降沿触发，那么一次按压可能产生 3 到 8 个下降沿，中断自然“连发”。
这也解释了为什么串口打印看到的中断间隔基本都在十几毫秒以内，和抖动窗口高度吻合。解决抖动的正确思路不是在中断里“数次数然后滤掉”，而是从边沿信号入口就把抖动窗口内的后续边沿全部忽略掉。
4. 一次“Always Fires”的真实排查链路
光知道根因还不够，我把自己第四次踩这个坑时的完整排查过程写出来。这个过程可能比任何单一答案都更有参考价值，因为你手里的现象未必和我完全一致，但排查路径是通用的。
4.1 第一步：让示波器自己说话
拿到故障板，先不要打开 IDE，先打开示波器，把探头夹在 PC13 上，地和板子 GND 相连。设置触发电平为 1.65V 左右，时基 20ms。
按下 B1 按钮，观察波形。正常应该是一个干净的低电平脉冲，下降沿清晰；有问题时则会看到一串连续的方波毛刺，或者在停止按下时示波器依然捕捉到随机下降沿。当时的实测波形让我排除了单纯的“按键内部损坏”，因为毛刺集中在按钮动作瞬间，更多指向抖动和浮空两个因素。
4.2 第二步：把代码砍到最朴素的最小复现工程
不要一上来就分析业务代码。重新建一个工程，只做三件事：
- 初始化 PC13 为输入，带上拉；
- 配置 EXTI 下降沿触发；
- 中断服务函数里只翻转板载 LED。
按一次按钮，观察 LED 翻转次数。如果按一下 LED 翻转了 4 次，说明问题在硬件抖动或 EXTI 配置层面，和你的业务逻辑无关。这一步能把排查范围一下子缩小大半。
4.3 第三步：用时间戳识别“抖动型触发”和“挂起型触发”
在最小工程里，每次进入中断都记录一个 32 位计数器当前值。不用串口打印，直接在中断里翻转一个备用 GPIO 引脚，用逻辑分析仪或示波器看两次翻转的间隔。
- 如果间隔在几毫秒到十几毫秒之间随机分布，说明是机械抖动导致的连续下降沿；
- 如果间隔极其固定且极短，说明是挂起位没清或边沿配置错误；
- 如果间隔在几十毫秒以上且每次按键都出现一批，说明 ISR 处理时间过长，抖动窗口被拉进了处理流程。
4.4 第四步：逐项修复后做稳定性验证
我最终把问题拆成了三个层次，分别修复：
- 把 PC13 配置为内部上拉，保证常态电平稳定；
- 触发方式只保留下降沿；
- 在 ISR 中不做任何延时，只置一个标志位，消抖放到主循环里用延迟重读处理。
修复后做了 100 次按压测试，每次间隔 0.5 秒，中断次数和按钮按下次数完全一致，没有再出现一次多余触发。
5. 一份可靠的中断按键实现，以及为什么这样写
这一节给出的是经过验证、可以直接参考的实现。我用的是 HAL 库加 CubeMX 生成的基础工程，但关键代码都做了说明，方便你自己调整。
5.1 推荐的基础配置
| 配置项 | 值 | 理由 |
|---|---|---|
| GPIO Mode | GPIO_MODE_IT_FALLING | 按钮按下为低电平有效，只关心下降沿 |
| GPIO Pull | GPIO_PULLUP | 按钮释放时引脚被拉高，避免浮空 |
| NVIC 优先级 | 5（抢占优先级） | 避免和 SysTick、DMA 等抢占冲突 |
| ISR 内部动作 | 只置标志位 | 防止抖动窗口被 ISR 执行时间覆盖 |
5.2 GPIO 与中断初始化代码
static void MX_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStruct = {0}; __HAL_RCC_GPIOG_CLK_ENABLE(); __HAL_RCC_GPIOC_CLK_ENABLE(); // 板载 LED，用于调试翻转输出 HAL_GPIO_WritePin(GPIOG, GPIO_PIN_14, GPIO_PIN_RESET); GPIO_InitStruct.Pin = GPIO_PIN_14; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(GPIOG, &GPIO_InitStruct); // 按键 PC13：下降沿触发、内部上拉 GPIO_InitStruct.Pin = GPIO_PIN_13; GPIO_InitStruct.Mode = GPIO_MODE_IT_FALLING; GPIO_InitStruct.Pull = GPIO_PULLUP; HAL_GPIO_Init(GPIOC, &GPIO_InitStruct); HAL_NVIC_SetPriority(EXTI15_10_IRQn, 5, 0); HAL_NVIC_EnableIRQ(EXTI15_10_IRQn); }关键点在于GPIO_MODE_IT_FALLING已经决定了只响应下降沿，不会再被释放时产生的上升沿干扰；GPIO_PULLUP则给 PC13 一个明确的默认电平。
5.3 中断服务函数的标准骨架
void EXTI15_10_IRQHandler(void) { HAL_GPIO_EXTI_IRQHandler(EXTI_LINE_13); } void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == EXTI_LINE_13) { button_event = 1; // 只置标志位，不在中断里做任何耗时操作 } }这样写的目的很简单：把“检测到事件”和“处理事件”在时间上彻底分开。中断只负责告知主循环“按钮可能被按下了”，真正消耗时间的消抖和业务逻辑全部放在主循环。
5.4 消抖的两种实践：延迟重读 vs 定时器扫描
最直观的消抖方式是在主循环里做延迟重读：
while (1) { if (button_event) { button_event = 0; HAL_Delay(20); // 等待抖动结束 if (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) == GPIO_PIN_RESET) { HAL_GPIO_TogglePin(GPIOG, GPIO_PIN_14); } } }注意，如果某个任务需要长时间轮询，但又有多个功能，这种阻塞式的HAL_Delay不一定适合。更好的方案是使用一个 5ms 周期的定时器扫描按钮状态，代码不阻塞，适合复杂系统：
#define SAMPLE_MS 5 #define CONFIRM_CNT 4 // 20ms 确认窗口 void button_scan(void) { static uint8_t stable_level = 1; // 常态高 static uint8_t cnt = 0; uint8_t level = HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13); if (level != stable_level) { if (++cnt >= CONFIRM_CNT) { cnt = 0; stable_level = level; if (level == 0) { button_event = 1; } } } else { cnt = 0; } }这种定时器扫描方式不仅处理了抖动，还把“长按”“短按”“双击”等扩展需求留好了基础。主循环只消费button_event，整个流程不会被中断状态牵着鼻子走。
5.5 为什么不用“中断里做延时消抖”
很多人第一反应是中断触发后先延时 20ms 再读引脚，把这段代码放在 ISR 里。表面看能消抖，但实际上非常危险：ISR 被延时占住，其他中断无法及时响应；如果按键抖动窗口略长，还会出现“延时结束刚好错过稳定状态”的问题。更重要的是，这类做法把耗时操作放进了中断上下文，违背了中断处理的基本原则。
6. 从单片机到桌面 GUI：按钮事件“总触发”的通病
排查完 Nucleo-F746ZGT 上的问题后，我顺手想起了一些常见的热搜话题：QT 里限制按钮短时间内只能点一次、WPF 里怎么触发按钮点击事件、微信小程序里读取 button 内容。这些场景虽然平台不同，但按钮事件模型的本质惊人地相似，都是“边沿事件 vs 电平状态”的区别。
6.1 任何按钮事件，本质都是“状态变化”，不是“状态持续”
单片机的 EXTI 是边沿检测器，它不关心引脚现在是高还是低，只关心“从高变成低”这个动作。桌面 GUI 里的按钮事件也是一样，鼠标点击产生的是按下释放的完整过程，框架会在某个阶段发布一次Click事件，而不是在按住期间每隔一毫秒发布一次。
理解了这一点，你就能解释为什么 GUI 里做“按钮只能点一次”时，通常不是去读按钮当前状态，而是用一个时间锁或布尔标志把后续事件挡在窗口外。这和 STM32 的中断标志位逻辑是同一个思路。
6.2 QT、WPF、小程序里“防重复触发”的做法
在 QT 中用setEnabled(false)或时间戳过滤，在 WPF 中通过IsEnabled或DispatcherTimer做冷却窗口，在小程序里给 button 绑定一个disabled属性，本质上都是制造一个“事件屏蔽窗口”。这和我在 5.4 节里给出的 20ms 消抖窗口完全对应，只不过嵌入式里窗口是毫秒级，GUI 里窗口是几百毫秒级。
6.3 回到嵌入式：一条值得长期遵守的清单
不管你在哪个平台排查按钮问题，以下清单都值得保留：
- 先确认硬件的常态电平，再决定内部上拉还是下拉；
- 只配置你关心的边沿方向，不要图省事用双边沿；
- 确保中断挂起位被清除，HAL 库自动做，但手写寄存器时要自己负责；
- 中断里永远只做“记录事件”，把消抖和业务放到主循环或任务里；
- 消抖窗口要覆盖机械抖动的最长持续时间，一般 20ms 足够，劣质按键可以放大到 50ms；
- 用示波器或逻辑分析仪观察中断入口的 GPIO 翻转波形，比串口打印日志靠谱得多。
每次遇到这种“中断总是触发”的怪问题，我都会提醒自己：中断从来不撒谎，它只是在用你没有预期到的方式提醒你，某个配置或者某个时序出了问题。把引脚状态、触发边沿、消抖逻辑一步步查一遍，大部分 always fires 的场景都不会撑过半小时。
