Nucleo-F746ZGT按键中断多次触发问题及软件消抖方案

先把话说清楚：Nucleo-F746ZGT 这块板子，板载一个蓝色按键 B1，硬件上接到 PC13。把 PC13 配成外部中断，本意是“按键一按就立刻响应”。结果代码一烧进去就傻眼——按一下按键，中断像连珠炮一样触发好几次；有时候手指还没碰到按键，仅仅靠近板子边缘，中断就自己跑起来了。你去搜索引擎里几乎天天能看到这种标题的提问，典型的写法就是 “Nucleo-F746ZGT and interrupt on button pressing always fires”。

这篇文章就把这个问题的前因后果全部拆开。先说结论，再讲硬件原理，然后给出几种真正能落地的解决方案，最后附一套可以直接编译烧录的 HAL 工程代码。新手可以照着做，老手也能查查有没有漏掉的排查方向。无论是刚点亮 F7 开发板的小白，还是被按键抖动折磨过的嵌入式老油条，都能从里面捞到点东西。

1. 先说结论：这个“always fires”到底是什么问题

1.1 现象与影响

“always fires”这个描述，包含了三个等级：

• 按一下按键，中断触发多次。这是最典型的“一次物理按下，软件却收到一大串边沿事件”。
• 不按键，中断也触发。这通常不是抖动问题，而是引脚浮空、外部噪声耦合，导致电平一直在临界区跳变。
• 按一下只触发一次，但业务逻辑错误，比如 LED 翻转了四五次。这种情况经常是中断服务函数里做了延时或重活儿，导致嵌套或重入。

不管哪种，最终表现都是“按键行为完全不可控”。在真实项目里，这会影响计数、模式切换、菜单翻页、启停控制等功能。操作员按一次，设备却跑了两三次动作，轻则体验差，重则安全事故。所以这个问题必须根治，不能靠“少按几次”来掩盖。

1.2 问题本质

把“always fires”翻译成技术语言，其实就是一句话：

中断源产生的事件数量，和用户实际物理操作次数不一致。

造成这种不一致的原因通常有三层：机械抖动、电气噪声、软件设计问题。有意思的是，这个需求和桌面 UI 开发里的“限制按钮在一段时间内只能点按一次”本质上是同一件事——用户一次操作只允许产生一个业务事件。不管是 Qt、WPF 还是嵌入式裸机，底层逻辑都是“事件消抖”和“事件防重入”。理解了这一点，你就不只是在修一个 STM32 的问题，而是在理解整个事件驱动系统的共性。

2. 为什么按键按下会“连发”中断？核心原理拆解

2.1 先看一眼硬件：Nucleo 板载按键 B1 的接法

Nucleo-F746ZGT 的原理图上，B1 按键一端接 GND，另一端通过一个串联电阻（一般几百欧姆，起限流和简单滤波作用）接到 PC13。空闲时 PC13 的电平由谁来拉高？答案不是外部上拉电阻，而是 MCU 内部的上拉电阻。

STM32F746ZGT6 的数据手册里写得比较含糊，但内部上拉电阻的典型值在 30kΩ 到 50kΩ 之间。这个阻值对于数字电平维持来说没问题，但抗干扰能力很弱。旁边只要有一根带数字信号的飞线，或者人手靠近，耦合过去的噪声就可能把电平拉低到阈值以下，从而误触发。

另外注意，PC13 属于 EXTI15_10 中断线，对应的中断服务函数是 EXTI15_10_IRQHandler，而不是 EXTI0_IRQHandler。网上不少新手把中断回调函数写对了，却在启动文件或 stm32f7xx_it.c 里漏掉了 EXTI15_10_IRQHandler 对 HAL_GPIO_EXTI_IRQHandler 的调用，导致中断永远不执行。这个属于“另一个极端”,但也值得记一笔。

2.2 机械抖动怎么演变成“多次触发”

按键内部是金属弹片。按下和释放的瞬间，弹片不是一次性贴合或断开，而是会反弹几次，这个过程就叫机械抖动。持续时间一般在 5ms 到 20ms 之间，具体跟按键的机械结构和寿命有关。

用示波器看 PC13 的波形，你会发现一个“干净”的按键动作实际上是这样的：

1. 电平从高拉低（按下）
2. 低电平区间内出现多个毛刺脉冲（抖动）
3. 电平稳定在低电平（按住）
4. 释放时电平从低拉高，再次出现毛刺（释放抖动）
5. 最终稳定在高电平

如果把 PC13 配置成“上升沿 + 下降沿都触发”，那一次按下和释放，中途所有毛刺都会各产生一次中断。哪怕只配置下降沿触发，按下抖动期间也可能产生多个下降沿，于是触发多次。

2.3 中断配置的锅：边沿触发的天然缺陷

外部中断（EXTI）的本质是检测引脚电平跳变。它不知道这个跳变是人为按键还是机械抖动，只要满足沿条件，就会拉高中断标志。这是硬件层面的天然缺陷，边沿触发无法区分“第一次跳变”和“后续抖动跳变”。

我见过不少人把问题归结为“芯片坏了”，其实芯片冤枉得很。真正的破局方向就两条：

• 从硬件上消除抖动（RC 滤波、施密特触发器、专用消抖芯片）
• 从软件上过滤抖动（延时消抖、状态机、定时扫描）

Nucleo 板上没有针对 PC13 做额外滤波，所以软件方案是必须的。少数开发板会在按键电路上并一个 100nF 电容做硬件消抖，可以大幅减轻毛刺，但也不能保证完全消除，因为电容充放电时间有限。

3. 解决方案一：软件消抖，这是门槛最低的起点

3.1 最直接的延时消抖

所谓延时消抖，就是检测到电平变化后，先延时一段时间，再读取一次引脚电平，如果两次结果一致，才认为是有效动作。这是一种“用时间换稳定”的做法。

伪代码如下：

if (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) == GPIO_PIN_RESET) { HAL_Delay(10); // 跳过抖动窗口 if (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) == GPIO_PIN_RESET) { // 确认按下，执行逻辑 } }

这个方案有效，但有两个明显的坑。第一，HAL_Delay 在中断服务函数里不能随便用，因为它依赖 SysTick，而且会阻塞 CPU，极端情况下会造成中断重入或嵌套异常。第二，10ms 的延时在实时性要求高的场景下是不可接受的，比如按键要控制一个高速计数器的启停，延时期间计数器可能已经多跑了几百次。

所以，延时消抖适合用在主循环轮询场景，不太适合放在中断里。如果你目前只是做一个教学实验，想快速验证按键逻辑，可以先用这个方案跑通，但正式项目不建议。

3.2 状态机消抖：不阻塞、可扩展

状态机消抖是我在项目里用得最多的方案。它的核心思想是：不延时等待，而是周期性扫描按键电平，每次扫描都根据当前状态决定下一步跳转。因为扫描间隔很短（比如 2ms），所以不会漏掉快速点按，同时又能滤除 5~20ms 的机械抖动。

typedef enum { KEY_IDLE, // 空闲，等待按下 KEY_DEBOUNCE, // 检测到按下，进入消抖确认 KEY_PRESSED // 确认按下 } KeyState; KeyState key_state = KEY_IDLE; uint32_t debounce_time = 0; volatile uint8_t key_event = 0; void key_scan(void) { uint8_t level = HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13); switch (key_state) { case KEY_IDLE: if (level == GPIO_PIN_RESET) { key_state = KEY_DEBOUNCE; debounce_time = HAL_GetTick(); } break; case KEY_DEBOUNCE: if (level == GPIO_PIN_RESET) { if (HAL_GetTick() - debounce_time >= 15) { key_state = KEY_PRESSED; key_event = 1; // 产生一次有效按键事件 } } else { key_state = KEY_IDLE; // 抖动中反弹回高电平，取消 } break; case KEY_PRESSED: if (level == GPIO_PIN_SET) { key_state = KEY_IDLE; // 松开，回到初始状态 } break; default: key_state = KEY_IDLE; break; } }

这个函数可以在主循环里每一圈调用一次，也可以放到 SysTick 中断或定时器中断里，每 2ms 调用一次。整个扫描过程没有阻塞，消抖时间可以精确控制，不会卡住其他业务。把 key_event 在消费后清零，就能保证一次物理按下只产生一次业务事件。

3.3 定时器扫描方式：把按键当“轮询事件”处理

如果工程里已经有 RTOS，比如 FreeRTOS，那么可以开一个按键任务，每 2ms 扫描一次按键，用队列或事件标志把按键事件发给主控任务处理。这个思路和状态机本质上一样，只是把扫描逻辑封装成了独立任务，代码更整洁。

裸机环境也不必担心。可以用 TIM2 定时器中断，1ms 或 2ms 进入一次，在中断里调用 key_scan()。注意，key_scan() 里没有阻塞操作，所以放在定时器中断里是安全的，不会拖慢中断响应。

定时器扫描方式的好处是实时性和确定性都很好，按键状态机的状态也一目了然。调试的时候，你能很清楚地看出当前处于哪个状态：是按下消抖中，还是已经确认按下。这个对后续扩展“长按”“双击”非常有帮助，因为这些复杂手势本质上都是状态机的不同状态分支。

4. 解决方案二：重新设计中断触发逻辑

4.1 中断里只置位，干活全挪到主循环

既然“always fires”的核心是事件数量不对，那么一个非常有效的思路就是：中断发生后，不在中断里做任何业务判断，只用一个 volatile 变量将标志位置 1，然后立即退出。主循环检测到标志位后，再做完整的消抖和逻辑处理。

这个方案把“中断是否发生”和“按键是否有效”分成了两个阶段：中断只是通知“可能有按键动作”，主循环负责确认“这个动作是否真的有效”。

volatile uint8_t button_pressed_flag = 0; void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == GPIO_PIN_13) { button_pressed_flag = 1; // 只置位，不做其他事 } }

主循环中：

int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); uint32_t last_key_time = 0; while (1) { if (button_pressed_flag) { button_pressed_flag = 0; uint32_t now = HAL_GetTick(); // 时间窗口过滤：小于 20ms 的连续触发直接忽略 if ((now - last_key_time) < 20) { continue; } last_key_time = now; // 再次读取电平，确认确实处于按下状态 if (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13) == GPIO_PIN_RESET) { HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_0); } } } }

4.2 为什么要加上 20ms 时间窗口和电平确认

时间窗口的用意是：即使抖动产生的多个下降沿触发了多次中断，标志位被反复置 1，主循环在同一时刻也只会消费一次，因为第一次消费后，20ms 内后续的标志位都会被跳过。

电平确认的用意更直接：抖动可能让电平在低电平附近弹跳，但只有真正稳定在低电平时，才说明按键确实被按下了。这个二次读取虽然看上去很简单，但对误触发的抑制效果非常明显。

4.3 关于 __HAL_GPIO_EXTI_CLEAR_IT 的正确理解

不少人在中断回调里自己手动调用 __HAL_GPIO_EXTI_CLEAR_IT，其实在标准 HAL 库流程中，HAL_GPIO_EXTI_IRQHandler 在回调之前就已经清除挂起位了。你手动再清一次问题不大，但没必要。真正需要注意的反而是，如果引脚配置成了“上升沿 + 下降沿同时触发”，一次完整的按下和释放会产生两次中断，这时候再清一次标志也无济于事，因为第二次中断已经挂起了。

所以，正确的做法不是依赖清标志位，而是从源头上减少触发次数：只配置你关心的那个沿。比如想响应“按下”，就只配置下降沿触发（PC13 按键按下时接地，高电平变低电平），不要同时勾选上升沿。想响应“释放”，就只配置上升沿。

4.4 再进一步：事件队列封装

如果你做的产品有多个按键，而且每个按键都有短按、长按、双击、组合键等复杂需求，建议把按键事件封装成一个队列。中断回调或定时扫描只负责往队列里写入“原始事件”，主循环负责消费、判定手势、发出业务指令。这样“任意时刻只有一个业务动作”就能得到严格的保证，不会因为中断风暴导致事件积压。

5. 完整 HAL 工程代码示例：Nucleo-F746ZGT 按键控制 LED

5.1 CubeMX 配置要点

用 STM32CubeMX 打开 F746ZGT 工程时，几个关键配置如下：

• RCC：HSE 外部高速时钟，系统主频配到 216MHz。
• PC13：设置为 GPIO_EXTI13，GPIO mode 选择 External Interrupt with Falling edge detection，GPIO Pull 选择 Pull-up。
• PB0：设置为 GPIO_Output，初始电平为 Low。Nucleo-F746ZGT 板载绿色 LED 接在 PB0，低电平点亮。
• NVIC：在 System Core -> NVIC 中勾选 EXTI line[15:10] interrupts，抢占优先级设为 2，子优先级设为 0。

Configuration 里，PC13 的 User Label 可以改成 BTN1，PB0 改成 LED_GREEN，这样生成的代码可读性更好。注意 GPIO Pull 一定要选 Pull-up，这是很多人第一次烧代码就跑飞的关键原因。

5.2 生成的工程代码改哪里

CubeMX 生成的 main.c 里，MX_GPIO_Init() 函数中 PC13 的初始化大致如下：

GPIO_InitStruct.Pin = BTN1_Pin; GPIO_InitStruct.Mode = GPIO_MODE_IT_FALLING; GPIO_InitStruct.Pull = GPIO_PULLUP; HAL_GPIO_Init(BTN1_GPIO_Port, &GPIO_InitStruct); HAL_NVIC_SetPriority(EXTI15_10_IRQn, 2, 0); HAL_NVIC_EnableIRQ(EXTI15_10_IRQn);

这段代码本身没问题。重点是你需要在 main.c 里定义一个全局标志：

volatile uint8_t button_pressed_flag = 0;

然后在 stm32f7xx_it.c 里的 EXTI15_10_IRQHandler 中，确认调用了 HAL_GPIO_EXTI_IRQHandler：

void EXTI15_10_IRQHandler(void) { HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_13); }

最后在 main.c 末尾添加回调函数。注意，这个回调函数在 HAL 库里是弱符号，默认是什么都不做的。你重新定义一个同名强符号之后，中断里就会执行到你自己的版本：

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin == GPIO_PIN_13) { button_pressed_flag = 1; } }

主循环加上按键处理逻辑，整体就是一个可直接运行的小项目。编译烧录后，正常现象是：按一下 B1，LED 翻转一次；快速乱按，也不会出现一次按下去 LED 闪好几下的情况。

5.3 避坑：为什么不要在回调里加延时

有些初学者喜欢在 HAL_GPIO_EXTI_Callback 里写 HAL_Delay(10) 做消抖。这个过程本身可能“看起来能用”，但隐患很大。HAL_Delay 依赖 SysTick 中断，而你在外部中断里延时几十毫秒，会让整个系统卡死；如果同一时间还有更高优先级的中断需要响应，响应延迟会猛增。更严重的是，如果延时期间同一个按键再次触发中断，回调会重入，最终导致栈溢出。

我给过一个直观类比：中断回调就像是公司前台，正常情况下接到电话立刻记录并转交相关部门；而你非让前台在电话旁坐卡 20 秒再转交，那期间进来的所有电话都会堆积，系统自然乱套。

6. 排查实录：我的按键中断“always fires”的三次经历

6.1 第一次：引脚浮空，怪了一大圈

有次调试一块自制的 F746 板子，按键中断疯狂触发，甚至手靠近板子就触发。我一开始怀疑是代码问题，把 CubeMX 重新生成、中断回调改来改去，都没用。后来用万用表量 PC13 对地电压，发现空闲时电压只有 0.8V 左右，远低于高电平阈值。

原因就是 PC13 内部上拉没有使能，或者更准确地说，硬件上根本没接外部上拉电阻，引脚处于高阻态。高阻态下的引脚就像一个漂浮不定的气球，旁边任何电场变化都能影响它的电平。

修复方式非常简单：把 GPIO Pull 改成 Pull-up。如果手头有现成的 10kΩ 外部上拉电阻，从 PC13 接到 3.3V 也可以。这个坑属于“查得越久越丢人”，但真的不少见，尤其是从旧工程改引脚配置时容易漏。

6.2 第二次：ISR 里做了串口打印，触发风暴

还有一次是在中断回调里加了 printf，想打印按键状态调试。结果按一下按键，串口输出一大片日志。原因很简单：printf 通过串口阻塞发送，速度在 115200 波特率下一个字符大概 86 微秒，如果打印 30 个字符，ISR 就要占约 2.6ms。这段时间里，按键弹片还在继续抖动，后续抖动产生的下降沿触发新的中断，又进入回调，又打印，无限循环。

更麻烦的是，printf 内部通常会有锁或临界区管理，在中断上下文里调用非常容易引发死锁或状态错乱。我后来学到的规矩是：中断回调里绝对不做耗时操作、不调 printf、不调 HAL_Delay。调试信息全部搬到主循环里，通过标志位触发打印，一次只打一条。

6.3 第三次：M7 内核的 cache 和变量可见性问题

F746ZGT 用的是 Cortex-M7 内核，带 I-Cache 和 D-Cache。理论上，外设寄存器访问不受 D-Cache 影响，因为 STM32 的总线矩阵把外设区域默认配置成不可缓存；但如果你在代码里用了外部 SRAM 或自定义内存段，又没有正确配置 MPU，就可能出现“中断回调里改了变量，主循环却读不到最新值”的现象。

这个现象在调试时特别诡异，因为单步执行时变量是正常的，全速运行时却像丢了中断一样。我遇到的一次就是开优化后，中断回调里给全局变量赋值，主循环里读出来始终是旧值。排查到最后发现，除了变量需要加 volatile 之外，还需要在特定位置加 __DSB() 数据同步屏障指令，确保内存写入立即完成。

当然，对大多数裸机工程来说，只要变量加了 volatile，且代码放在 TCM 或 Flash 中运行，一般不会踩到这个坑。但如果你把工程从 F1 或 F4 移植到 F7，主频拉高、开优化、用外部存储，就要留意这类问题。

7. 常见问题速查表

8. 个人体会

按键中断“always fires”这个问题，表面上是配置问题，背后其实是嵌入式系统里“事件源”和“业务事件”的区分问题。修过几次之后，我养成了一个习惯：任何按键接入 MCU，第一件事不是写代码，而是用示波器观察引脚波形，搞清楚空闲电平、按下电平、抖动时间大概是多少。没有示波器时，可以写一个简单程序在主循环里把引脚电平变化打成时间戳，通过串口看波形特征。这一步能帮你省掉大量盲目试错的时间。

另外，我现在做按键的时候，很少把彻底防抖的逻辑全交给中断。更稳的思路是“尽量少用中断，或者中断只做唤醒”。中断唤醒 CPU，主循环或者定时任务负责确认、消抖、去重、处理业务。这种架构对单个按键、矩阵键盘、旋转编码器都适用，后续加双击、长按、组合键也只是状态机的扩展，而不是推翻重来。

最后一个小建议：工程里所有中断回调会修改的变量，一律加 volatile。这个习惯救过我很多次，也希望能帮你在 F7 上少折腾一个通宵。