玩 STM32 的人大概率都撞到过这类怪事明明代码里没写 USB 相关的初始化可是 PA11/PA12 这两个引脚就是不听话——接 CAN 收发器时 CAN 报文满天飞乱码配置成普通 GPIO 输出时电平也拉不动甚至用示波器一量能看到一串一串的差分脉冲像是有什么东西在拼命往线上发数据。我曾经被这个问题折磨过整整一个晚上最后发现“抢”走这两个引脚的正是 STM32 内部集成的 USB 外设而它之所以能抢靠的是引脚复用配置、USB 收发器供电、内部上拉电阻这几个开关叠加在一起。这篇文章就围绕“USB 为什么能控制共享的 DP/DM 引脚”这个问题把背后的机制、排查流程和正确的释放方法完整拆开讲清楚。如果你正在做 USB 转串口、CAN 节点、DFU 烧录或者电路上不小心把 PA11/PA12 同时留给了 USB 和别的外设这篇文章应该能帮你少走不少弯路。1. 问题现象整理什么情况下会觉得“USB抢走了PA11/PA12”1.1 经典故障现场CAN或SPI设备在PA11/PA12上出现“幽灵数据”STM32 的 PA11/PA12 是出了名的多功能复用引脚在 F407 这样的芯片上PA11 可以接到 CAN1_RX、SPI1_MISO、USART1_CTS、TIM1_CH4也可以接到 USB_OTG_FS 的 DMPA12 对应 CAN1_TX、SPI1_MOSI、USART1_RTS、TIM1_ETR以及 USB_OTG_FS 的 DP。很多项目为了省引脚会把 CAN 或 SPI 直接安排在这两个脚上。这种方案的隐患在于只要 USB 外设的时钟被打开、收发器退出掉电PA11/PA12 就会同时存在两条“驱动路径”———条是 GPIO 复用网络里你配置的 CAN/SPI 功能另一条是 USB 收发器的专用模拟通路。板子上 PC 通过 USB 线插入时USB 主机端会立刻开始检测设备连接DP/DM 上会出现持续的 USB 协议信号比如低速/全速的包、SE0 状态、复位信号等。这些信号会直接叠加到同一物理引脚上CAN 收发器看到的就是电平频繁跳变表现在总线上就是 CRC 错误、帧错误甚至整个总线被拉死。我自己遇到过的情况是CAN 波特率 500kCAN_H/CAN_L 波形示波器测起来非常干净但只要 USB 线插到开发板节点就像发了疯一样发错误帧。拔掉 USB 线一切恢复正常。当时先怀疑电源结果 VBUS 纹波很小又怀疑共地最后用逻辑分析仪同时抓 PA11/PA12才看到 USB 枚举时特有的包络波形。问题根源就是 USB 外设也挂在同一个引脚上。1.2 经典故障现场GPIO输出电平不受控测量到USB波形还有一种更隐蔽的场景。有些同学把 PA11/PA12 配置成普通推挽输出想让它们驱动 LED 或者读取按键状态。代码看起来完全正常GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin GPIO_PIN_11 | GPIO_PIN_12; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_VERY_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_11 | GPIO_PIN_12, GPIO_PIN_SET);理论上这两个脚应该输出稳定的高电平但万用表量出来却是 0V 或者忽高忽低示波器上看到的不是直流电平而是密密麻麻的脉冲。这里的核心原因是GPIO 的 MODER 寄存器虽然被设置成了输出模式但如果 USB 外设的收发器仍然处于工作状态USB 的驱动能力和协议信号会直接表现在引脚上普通 GPIO 输出缓冲器根本顶不住。如果你的 USB 线已经连接到 PCPC 端 USB 主机为了检测设备会在 D/D- 上各挂一个 15kΩ 下拉电阻同时不停发送检测信号。你这边 GPIO 输出 3.3V 高电平对主机来说设备端上拉尚未出现主机认为“设备未连接”于是持续在总线上做状态翻转。最终引脚电位被主机的下拉电阻和 USB 收发器电路共同影响表现出来就是“你配了输出但它根本不听你的”。1.3 经典故障现场调试器断开后程序跑飞USB枚举却一直存在第三种情况也很常见板子自带 ST-Link 或者板载 USB 转串口调试口和 USB 口靠得很近。你只运行了一个普通 LED 闪烁的程序没碰 USB但插上 USB 线后电脑会“叮咚”一声识别出一个未知设备或者识别成某个 Bootloader 串口。把调试器断开后程序依然“跑飞”实际上是 CPU 的 Boot 引脚状态决定它进入了一个特殊的系统 Bootloader这个 Bootloader 内部自带 USB DFU 支持天然会把 PA11/PA12 占掉。这在系统存储区 Bootloader 存在的芯片上很容易发生。BOOT0 引脚被拉高时芯片启动后进入 System Memory里面出厂就有一段固件它会自动检测 USB 主机是否连接如果插着线立刻用 PA11/PA12 做 DFU 枚举。这种情况下你写的 App 根本没有运行但是 PA11/PA12 上却充满了 USB 活动。很多初学者会误以为“程序跑飞了”其实只是启动模式不对。2. 引脚归属权之争AFR复用开关和USB收发器的“双路径”2.1 STM32引脚是怎么“切换”给一个外设的要搞清楚 USB 为什么能抢引脚先得明白 STM32 的引脚复用是怎么工作的。除了少数纯模拟引脚每个 GPIO 引脚内部其实有好几套外设接口通过一组开关来切换。这个开关主要由 MODER 寄存器和 AFR 寄存器控制。MODER 决定引脚方向输入、输出、复用功能、模拟模式。当 MODER 切到复用功能模式时AFRL/AFRH也就是 AFR[0]/AFR[1]里每个引脚占 4 个 bit用来选择具体是哪一路外设编号从 AF0 到 AF15。以 STM32F407 为例PA11 和 PA12 的 AF10 对应 USB_OTG_FSAF9 对应 CAN1AF7 对应 USART1 的 CTS/RTSAF5 对应 SPI1 的 MISO/MOSI。这个选择逻辑相当于一个多路选择器AFR选中的外设信号 ——→ 引脚输出缓冲器 ——→ 物理引脚从纯 GPIO 角度理解USB 外设和其他外设都在同一张“会议室排期表”里竞争。USB 能占用这个会议室的前提是你把 AFR 写成了 AF10。所以第一个关键点在系统层面USB 并不会非法篡改你在 GPIO 里写的配置它只会在你给它排期之后才接管引脚。2.2 关键认知USB收发器不是普通AF外设它有专用模拟通路这里有一个很容易被忽略的硬核知识点对于 STM32F4 和常见带 USB 功能的型号USB 物理层收发器并不是完全依赖 AFR 多路选择器的。USB 的 DP/DM 信号是差分模拟信号收发器内部集成了比较器、上拉电阻控制、ESD 保护等模拟前端这些模拟前端到引脚之间的连接路径是相对固定的。换句话说你把 AFR 改成 AF9CAN时数字逻辑层面确实把 CAN 收发器接到了引脚上但 USB 收发器内部的模拟前端仍然通过半导体工艺与引脚有着物理连接。如果 USB 收发器没有被断电、没有进入 PowerDown 状态它内部的偏置电路、上拉控制、接收比较器就可能继续影响引脚电平。可以拿生活里的“会议室分配表”来类比AFR 寄存器像前台排期表写谁的名字就轮到谁。但 USB 收发器更像是会议室里的“固定投影仪”只要它没断电哪怕排期表上没有它投影仪依然开着图像就还能投在幕布上。两者不能混为一谈。这也是很多人“明明配置了 GPIO 输出但 PA11/PA12 依然被 USB 干扰”的根因所在。你要做的不是只改 AFR 寄存器而是需要从供电和掉电状态上把 USB 收发器彻底“断电”。2.3 为什么USB必须加内部上拉DP/DM电平协议要求USB 1.1/2.0 低速和全速设备在电气上有一个很重要的约定空闲状态下D 或 D- 上有上拉电阻主机端有下拉电阻。全速设备在 D 上放 1.5kΩ 上拉到 3.3V主机端 D/D- 各放 15kΩ 下拉到地。这样当设备插入时主机检测到 D 被拉高立刻意识到“有设备来了”然后开始枚举流程。这意味着如果 STM32 的 USB 外设被软件接通了内部上拉即使你的用户代码没有主动发送任何数据主机也会通过 D 电平变化感知到设备插入随后发出总线复位、SOF 包、SetAddress 请求等。PA11/PA12 上立刻就有了真正的 USB 协议波形。换句话说USB “抢走”引脚的最直接表现就是它在引脚上制造了协议电平而你的普通 GPIO 逻辑没法覆盖它。3. “什么都没有做”的USB为什么会输出电平初始化链路上的四个开关3.1 第一个开关GPIO的MODER和AFR配置这一层是我们能在代码里主动控制的。CubeMX 生成代码时如果使能了 USB_OTG_FS它会自动在HAL_PCD_MspInit()里做这样的配置static void HAL_PCD_MspInit(PCD_HandleTypeDef* hpcd) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_USB_OTG_FS_CLK_ENABLE(); /**USB_OTG_FS GPIO Configuration PA11 ------ USB_OTG_FS_DM PA12 ------ USB_OTG_FS_DP */ GPIO_InitStruct.Pin GPIO_PIN_11 | GPIO_PIN_12; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate GPIO_AF10_OTG_FS; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); }这段代码不可谓不“霸道”它把 PA11/PA12 的 MODER 设置为复用功能AFR 设为 AF10。一旦执行从 GPIO 层面看这两个引脚就已经交给 USB 模块了。所以如果你在项目工程文件里加载过 CubeMX 生成的 USB 设备中间件或者从示例工程复制了代码那么哪怕你从来没有调用HAL_PCD_Start()只要MX_USB_DEVICE_Init()被调用过这个开关就已经合上了。在排查时第一步就是去 IDE 的 Register 窗口看GPIOA-AFR[1]或者直接读这个寄存器。PA11 对应 AFR[1] 的 bit[11:8]PA12 对应 bit[15:12]值应该是 0xA也就是十进制 10。3.2 第二个开关外设时钟与收发器电源控制PWRDWN光有 GPIO 复用配置还不够USB 收发器自身也需要工作在“非掉电”状态。在 F4 系列上USB OTG_FS 模块挂在 AHB1 总线上你需要在 RCC 中打开它的时钟__HAL_RCC_USB_OTG_FS_CLK_ENABLE();时钟打开后收发器是否真正工作还看USB_OTG_FS_GCCFG寄存器里的PWRDWNPower Down位。初始状态下这一位通常为 1表示收发器处于掉电状态。HAL 库在HAL_PCD_Init()内部会把 PWRDWN 清零让收发器走出掉电。此时 USB 的数据收发电路才真正“通电”才会作用到 PA11/PA12 引脚上。所以第二个排查点是USB_OTG_FS_GCCFG的 PWRDWN 位是否为 0。如果为 0说明 USB 收发器正在工作即使你不想用它它也在“盯着”引脚。对于带 VDDUSB 独立供电的芯片还要额外确保 VDDUSB 供电正常或者通过HAL_PWREx_EnableUSBRegulator()这类接口打开内部稳压器。如果 USB 模块没有供电收发器自然也就不会工作。3.3 第三个开关内部上拉电阻USB主机识别设备的“钩子”USB 设备要想被主机识别必须让主机看到设备端的上拉。很多 STM32 芯片内部已经集成了这个上拉电阻不需要你在外面再加。例如USB OTG_FS 做全速设备时D 上的内部上拉由寄存器位控制而一些老款型号比如 STM32F103则需要通过软件控制 DP 引脚的上拉或者通过 PA8 引脚外接上拉。只要这个上拉被接通主机就会认为“设备已连接”立刻发起枚举。因此第三个排查点是DP/DM 引脚上是否存在一个 1.5kΩ 左右的上拉源以及这个上拉是由谁控制的。如果是芯片内部上拉且被程序打开了那么即使没有跑任何业务代码枚举也会自动进行。3.4 第四个开关系统Bootloader的DFU检测这一个开关和你的用户代码无关但在实际项目里制造了最多的“灵异事件”。STM32 系统存储区里的出厂 Bootloader在特定启动条件下会检测 USB 主机是否连接。它会占住 PA11/PA12主动完成 USB DFU 枚举并等待上位机下发 DFU 命令。触发条件是 BOOT01、BOOT10或者由 Option Bytes 配置的启动模式此时 CPU 复位后会跳到 System Memory。如果你在这时候插了 USB 线DP/DM 上就会持续出现 USB 枚举流量。这解释了为什么很多新手发现代码明明烧录了一上电 LED 却不闪插上 USB 电脑反而识别出“STM32 Bootloader”。排查方法很简单看 BOOT0 引脚的电平用万用表量一下复位瞬间的启动状态。另外IDE 里如果发现程序计数器停在 0x1FFFxxxx 这种地址多半就是进了系统 Bootloader。4. 复现一次完整排查示波器、寄存器、CubeMX三步定位4.1 第1步用示波器或逻辑分析仪确认波形形态当你怀疑 PA11/PA12 被 USB 抢占不要急着改代码先看波形。把示波器探头夹到 PA11/PA12 和 GND 之间触发方式设为单次或自动观察空闲电平和活动时的波形。普通 GPIO 输出高电平应该稳定在 3.3V输出低电平应该稳定在 0V。如果波形出现高频差分脉冲或者出现长时间的低电平并偶尔有突发包那就要高度怀疑 USB 活动。USB 全速信号速率是 12Mbps建议用 50MHz 以上带宽的示波器带宽不够可能只看到一团模糊的噪声。如果有逻辑分析仪采样率至少在 48MHz 以上否则抓不到完整的包结构。抓包时不要只抓一根线最好把 D 和 D- 一起抓因为 USB 是差分信号两根线是互补的。如果只抓一根线看到的是单端 3.3V 翻转还不够直观。抓完波形后数一下包间隔如果规律地出现大约每毫秒一次的 SOF 包那基本就是 USB 主机在周期性广播帧起始包USB 链路已经被激活。4.2 第2步查GPIO复用寄存器和USB寄存器锁定“谁合上了开关”波形只是表象下一步要从寄存器层面确认。最直接的方法是在调试器里打开 Register 窗口或者用 IAR/Keil 的 Watch 窗口添加表达式GPIOA-MODER GPIOA-AFR[1] RCC-AHB1ENR USB_OTG_FS-GCCFG重点看这几个字段寄存器关键位含义GPIOA-MODERbit[23:22] / bit[25:24]PA11/PA12 模式2b10 表示复用功能GPIOA-AFR[1]bit[11:8] / bit[15:12]0xAAF10说明配给了 USB_OTG_FSRCC-AHB1ENRbit28USB_OTG_FS 时钟是否使能1使能USB_OTG_FS-GCCFGPWRDWN1掉电0正常工作如果 AFR 是 0xA说明是 CubeMX 或者你的初始化代码把引脚切给了 USB。如果 AFR 不是 0xA但波形依然有 USB 活动那就要怀疑是不是 Bootloader 在接管或者外部电路比如 USB PHY 芯片、板载 USB 转串口芯片直接把信号拉到了引脚上。4.3 第3步翻CubeMX配置和启动代码找源头寄存器告诉我们“当前是谁在控制”但要解决问题还得找到“为什么会走到这个状态”。通常有三个入口打开项目里的main.c看是否调用了MX_USB_DEVICE_Init()。CubeMX 在使能 USB 之后即使你的业务功能没有用到 USB它也会在初始化序列里调用这个函数。看usbd_conf.c里的HAL_PCD_MspInit()确认 GPIO 和时钟配置。检查 BOOT0 引脚。如果量产板 BOOT0 被拉高或者用户在设计时预留跳线帽芯片启动后可能进入 DFU Bootloader。这里有个很典型的坑CubeMX 工程从某个示例模板复制而来示例把 USB Device 使能了你自己在这个工程上加了 UART 或 CAN 业务。如果你没留意 CubeMX 界面里 USB_OTG_FS 那一栏它可能一直被勾选着。生成的初始化代码就会默默把 PA11/PA12 切给 USB。这种问题最烦人因为代码看起来“我没有主动调用 USB”但实际上启动阶段立方体生成的MX_USB_DEVICE_Init()已经做完了整个初始化。5. 释放引脚的正确姿势关掉USB外设再恢复复用功能5.1 标准操作流程和HAL库代码如果你的业务根本不需要 USB只是想让 PA11/PA12 安安稳稳做 CAN/SPI/GPIO正确顺序是先停掉 USB 外设、关闭 USB 时钟再配置 GPIO 复用功能。别反过来否则 STM32 的 USB 模拟前端仍可能因为供电和掉电状态未恢复继续影响引脚。下面以 STM32F407 为例写一段标准的“释放引脚”流程。假设工程里已经有 USB 设备句柄hpcd// 1. 如果有 USB 句柄先 DeInit让 PCD 回到初始状态 if (hpcd.Instance ! NULL) { HAL_PCD_DeInit(hpcd); } // 2. 关闭 USB OTG FS 时钟让外设彻底失去时钟源 __HAL_RCC_USB_OTG_FS_CLK_DISABLE(); // 3. 等待几个周期确保内部状态机复位实际延时可放短一点 HAL_Delay(1); // 4. 重新配置 PA11/PA12 为需要的复用功能 // 这里以 CAN1 的 RX/TX 为例AF9 GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitStruct.Pin GPIO_PIN_11 | GPIO_PIN_12; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate GPIO_AF9_CAN1; HAL_GPIO_Init(GPIOA, GPIO_InitStruct);如果你的工程里没有 USB 句柄可以直接从第 2 步开始。但要注意如果 USB 时钟都没开那 USB 收发器自然不工作第 2 步可以省略。尤其注意第 4 步AFR 一定要改成你实际使用的外设编号不要只改 MODER 到 GPIO 输出模式因为 USB 收发器的模拟通路仍在物理上挂着彻底停止 USB 时钟和掉电状态才是关键。使用 GPIO 输出模式时也同理建议在配置 GPIO 前无论如何都先执行一次__HAL_RCC_USB_OTG_FS_CLK_DISABLE()。这是保证 USB 模拟前端完全失去时钟和唤醒源的有效方法。5.2 共用引脚时的电路级处理跳线、上下拉和USB MUX有的项目确实想同时保留 USB 和 CAN 这两路功能不想二选一。这时候软件层面可以不断切换但容易踩到枚举过程导致设备反复断开重连的坑。更稳妥的做法是从电路设计上做隔离。我比较推荐两种方案板上加 3 针跳线。把 PA11/PA12 通过排针引出一组跳到 USB 座一组跳到 CAN 收发器。用户用哪种功能就插哪组跳线。虽然要多花一个跳线帽的成本但排查问题时的幸福感极高。使用模拟开关或 USB 2:1 MUX。比如 TS3USB221A 这类芯片可以用 GPIO 控制 D/D- 的通路把 USB 差分对切换到不同目标。注意 USB 全速信号是 12Mbps要求模拟开关的带宽足够高导通电阻尽量小否则会影响信号完整性。还有一点容易被忽略如果你用了外部 USB 转串口芯片比如 CH340、FT232它本身是一个 USB Device内部自带 D/D- 上拉切记不要跟 MCU 的 PA11/PA12 直连。很多人的板子上有两个 USB 口其中一个是 USB 转串口芯片另一个是 MCU 原生 USB如果布线时把这两组差分对并在一起就会出现互相干扰、枚举失败的现象。5.3 如何验证释放是否成功释放完引脚不能光看代码逻辑觉得“应该好了”我习惯做三个验证用调试器读USB_OTG_FS-GCCFG确认 PWRDWN1即收发器处于掉电。读RCC-AHB1ENR确认 USB_OTG_FS 时钟位为 0。把 PA11/PA12 配置为 GPIO 输出拉高 3.3V用万用表实测引脚电压。如果第 3 步测出来还是奇怪的电压就要检查外部硬件了比如板子上是否有其他设备的输出直接连到了 PA11/PA12或者调试器本身占用了这些引脚。软件闭环验证通过后再插 USB 线电脑不应该再识别到任何新设备因为设备端已经失去的上拉主机永远不会发现它。6. 少踩坑的经验总结PA11/PA12使用自测清单与几个习惯6.1 一张可以直接抄的自测清单经过这几年做了好几个带 USB 的 STM32 项目我整理了一个“PA11/PA12 被抢自查清单”。每次遇到类似现象按顺序过一遍基本都能定位检查项方法正常状态BOOT0 启动引脚万用表量 BOOT0 电压或看启动配置用户 Flash 模式下应为低电平GPIO MODER查看 GPIOA-MODER应是你要用的功能模式GPIO AFR查看 GPIOA-AFR[1]不应是 AF10除非有意配置 USBUSB 时钟查看 RCC-AHB1ENR 的 bit280关闭USB 收发器掉电查看 USB_OTG_FS-GCCFG 的 PWRDWN1掉电0工作是否为系统 Bootloader查 PC 端是否识别出“STM32 Bootloader”设备不应出现外部硬件干扰看原理图 USB 差分对是否直接并联到 PA11/PA12不共用或已隔离这张清单我打印出来贴在工作台旁边有一次帮朋友排查一块板子两分钟就定位到问题他的 BOOT0 跳线帽插反了芯片一直在 System Bootloader 里跑 DFUPA11/PA12 当然全是 USB 波形。这种问题靠读代码永远读不出来必须从启动条件入手。6.2 我在实际项目中养成的几个习惯最后分享几个代码之外的实操习惯都是踩坑踩出来的经验。第一画板之前先做引脚分配表把 USB、CAN、UART 这类外设的引脚冲突列出来。PA11/PA12 一旦给了 USB就别再安排其它外设否则后续调试会非常痛苦。如果引脚紧张优先在电路板上留跳线而不是靠软件切换。第二CubeMX 里不用的外设一定要显式设成 Disable。很多人觉得“默认未勾选就是没用”其实从示例工程复制配置时USB 可能已经被勾选了却不自知。生成代码后在MX_USB_DEVICE_Init()这个函数名里看到“USB”三个字母就要多留一个心眼。第三启动代码里如果项目完全不用 USB可以在main()最开始就放一行__HAL_RCC_USB_OTG_FS_CLK_DISABLE();这一步等于“关门上锁”即使后面有外设误调用了 USB 初始化时钟不打开很多坑就能提前避开。当然如果后面需要用到 USB再把时钟打开也不迟。第四遇到“引脚奇怪”的问题别急着怀疑编译器、怀疑库函数、怀疑人生。先用示波器看波形再读寄存器。我第一次遇到 PA11/PA12 被 USB 抢占时就是直接在 GPIO 配置上反复改折腾了几个小时后来看了一眼GPIOA-AFR[1]瞬间明白了。寄存器不是洪水猛兽它就是让你快速对线的工具。6.3 回到题目本身一句话回答USB为什么能控制共享的DP/DM引脚把整篇文章压缩成一句话回答 FAQ 的标题USB 能控制共享的 DP/DM 引脚不是因为它有“特权”而是因为 GPIO 的复用开关、USB 外设的时钟/电源使能、内部上拉电阻以及启动模式这四个环节中的任意几个共同作用把引脚的使用权交给了 USB 收发器。收发器一旦开机并退出掉电它就在物理层面驱动了 PA11/PA12普通 GPIO 输出自然压不住。如果你想用这两个引脚做别的事记住这几件事就能避开绝大多数坑检查 BOOT0、检查 AFR、关掉 USB 时钟、确认收发器进入掉电状态。软件层面把这些开关都归位硬件层面做跳线隔离PA11/PA12 就老老实实听你指挥了。
STM32的USB为何抢走PA11/PA12？引脚复用与释放技巧全解析
玩 STM32 的人大概率都撞到过这类怪事明明代码里没写 USB 相关的初始化可是 PA11/PA12 这两个引脚就是不听话——接 CAN 收发器时 CAN 报文满天飞乱码配置成普通 GPIO 输出时电平也拉不动甚至用示波器一量能看到一串一串的差分脉冲像是有什么东西在拼命往线上发数据。我曾经被这个问题折磨过整整一个晚上最后发现“抢”走这两个引脚的正是 STM32 内部集成的 USB 外设而它之所以能抢靠的是引脚复用配置、USB 收发器供电、内部上拉电阻这几个开关叠加在一起。这篇文章就围绕“USB 为什么能控制共享的 DP/DM 引脚”这个问题把背后的机制、排查流程和正确的释放方法完整拆开讲清楚。如果你正在做 USB 转串口、CAN 节点、DFU 烧录或者电路上不小心把 PA11/PA12 同时留给了 USB 和别的外设这篇文章应该能帮你少走不少弯路。1. 问题现象整理什么情况下会觉得“USB抢走了PA11/PA12”1.1 经典故障现场CAN或SPI设备在PA11/PA12上出现“幽灵数据”STM32 的 PA11/PA12 是出了名的多功能复用引脚在 F407 这样的芯片上PA11 可以接到 CAN1_RX、SPI1_MISO、USART1_CTS、TIM1_CH4也可以接到 USB_OTG_FS 的 DMPA12 对应 CAN1_TX、SPI1_MOSI、USART1_RTS、TIM1_ETR以及 USB_OTG_FS 的 DP。很多项目为了省引脚会把 CAN 或 SPI 直接安排在这两个脚上。这种方案的隐患在于只要 USB 外设的时钟被打开、收发器退出掉电PA11/PA12 就会同时存在两条“驱动路径”———条是 GPIO 复用网络里你配置的 CAN/SPI 功能另一条是 USB 收发器的专用模拟通路。板子上 PC 通过 USB 线插入时USB 主机端会立刻开始检测设备连接DP/DM 上会出现持续的 USB 协议信号比如低速/全速的包、SE0 状态、复位信号等。这些信号会直接叠加到同一物理引脚上CAN 收发器看到的就是电平频繁跳变表现在总线上就是 CRC 错误、帧错误甚至整个总线被拉死。我自己遇到过的情况是CAN 波特率 500kCAN_H/CAN_L 波形示波器测起来非常干净但只要 USB 线插到开发板节点就像发了疯一样发错误帧。拔掉 USB 线一切恢复正常。当时先怀疑电源结果 VBUS 纹波很小又怀疑共地最后用逻辑分析仪同时抓 PA11/PA12才看到 USB 枚举时特有的包络波形。问题根源就是 USB 外设也挂在同一个引脚上。1.2 经典故障现场GPIO输出电平不受控测量到USB波形还有一种更隐蔽的场景。有些同学把 PA11/PA12 配置成普通推挽输出想让它们驱动 LED 或者读取按键状态。代码看起来完全正常GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin GPIO_PIN_11 | GPIO_PIN_12; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_VERY_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); HAL_GPIO_WritePin(GPIOA, GPIO_PIN_11 | GPIO_PIN_12, GPIO_PIN_SET);理论上这两个脚应该输出稳定的高电平但万用表量出来却是 0V 或者忽高忽低示波器上看到的不是直流电平而是密密麻麻的脉冲。这里的核心原因是GPIO 的 MODER 寄存器虽然被设置成了输出模式但如果 USB 外设的收发器仍然处于工作状态USB 的驱动能力和协议信号会直接表现在引脚上普通 GPIO 输出缓冲器根本顶不住。如果你的 USB 线已经连接到 PCPC 端 USB 主机为了检测设备会在 D/D- 上各挂一个 15kΩ 下拉电阻同时不停发送检测信号。你这边 GPIO 输出 3.3V 高电平对主机来说设备端上拉尚未出现主机认为“设备未连接”于是持续在总线上做状态翻转。最终引脚电位被主机的下拉电阻和 USB 收发器电路共同影响表现出来就是“你配了输出但它根本不听你的”。1.3 经典故障现场调试器断开后程序跑飞USB枚举却一直存在第三种情况也很常见板子自带 ST-Link 或者板载 USB 转串口调试口和 USB 口靠得很近。你只运行了一个普通 LED 闪烁的程序没碰 USB但插上 USB 线后电脑会“叮咚”一声识别出一个未知设备或者识别成某个 Bootloader 串口。把调试器断开后程序依然“跑飞”实际上是 CPU 的 Boot 引脚状态决定它进入了一个特殊的系统 Bootloader这个 Bootloader 内部自带 USB DFU 支持天然会把 PA11/PA12 占掉。这在系统存储区 Bootloader 存在的芯片上很容易发生。BOOT0 引脚被拉高时芯片启动后进入 System Memory里面出厂就有一段固件它会自动检测 USB 主机是否连接如果插着线立刻用 PA11/PA12 做 DFU 枚举。这种情况下你写的 App 根本没有运行但是 PA11/PA12 上却充满了 USB 活动。很多初学者会误以为“程序跑飞了”其实只是启动模式不对。2. 引脚归属权之争AFR复用开关和USB收发器的“双路径”2.1 STM32引脚是怎么“切换”给一个外设的要搞清楚 USB 为什么能抢引脚先得明白 STM32 的引脚复用是怎么工作的。除了少数纯模拟引脚每个 GPIO 引脚内部其实有好几套外设接口通过一组开关来切换。这个开关主要由 MODER 寄存器和 AFR 寄存器控制。MODER 决定引脚方向输入、输出、复用功能、模拟模式。当 MODER 切到复用功能模式时AFRL/AFRH也就是 AFR[0]/AFR[1]里每个引脚占 4 个 bit用来选择具体是哪一路外设编号从 AF0 到 AF15。以 STM32F407 为例PA11 和 PA12 的 AF10 对应 USB_OTG_FSAF9 对应 CAN1AF7 对应 USART1 的 CTS/RTSAF5 对应 SPI1 的 MISO/MOSI。这个选择逻辑相当于一个多路选择器AFR选中的外设信号 ——→ 引脚输出缓冲器 ——→ 物理引脚从纯 GPIO 角度理解USB 外设和其他外设都在同一张“会议室排期表”里竞争。USB 能占用这个会议室的前提是你把 AFR 写成了 AF10。所以第一个关键点在系统层面USB 并不会非法篡改你在 GPIO 里写的配置它只会在你给它排期之后才接管引脚。2.2 关键认知USB收发器不是普通AF外设它有专用模拟通路这里有一个很容易被忽略的硬核知识点对于 STM32F4 和常见带 USB 功能的型号USB 物理层收发器并不是完全依赖 AFR 多路选择器的。USB 的 DP/DM 信号是差分模拟信号收发器内部集成了比较器、上拉电阻控制、ESD 保护等模拟前端这些模拟前端到引脚之间的连接路径是相对固定的。换句话说你把 AFR 改成 AF9CAN时数字逻辑层面确实把 CAN 收发器接到了引脚上但 USB 收发器内部的模拟前端仍然通过半导体工艺与引脚有着物理连接。如果 USB 收发器没有被断电、没有进入 PowerDown 状态它内部的偏置电路、上拉控制、接收比较器就可能继续影响引脚电平。可以拿生活里的“会议室分配表”来类比AFR 寄存器像前台排期表写谁的名字就轮到谁。但 USB 收发器更像是会议室里的“固定投影仪”只要它没断电哪怕排期表上没有它投影仪依然开着图像就还能投在幕布上。两者不能混为一谈。这也是很多人“明明配置了 GPIO 输出但 PA11/PA12 依然被 USB 干扰”的根因所在。你要做的不是只改 AFR 寄存器而是需要从供电和掉电状态上把 USB 收发器彻底“断电”。2.3 为什么USB必须加内部上拉DP/DM电平协议要求USB 1.1/2.0 低速和全速设备在电气上有一个很重要的约定空闲状态下D 或 D- 上有上拉电阻主机端有下拉电阻。全速设备在 D 上放 1.5kΩ 上拉到 3.3V主机端 D/D- 各放 15kΩ 下拉到地。这样当设备插入时主机检测到 D 被拉高立刻意识到“有设备来了”然后开始枚举流程。这意味着如果 STM32 的 USB 外设被软件接通了内部上拉即使你的用户代码没有主动发送任何数据主机也会通过 D 电平变化感知到设备插入随后发出总线复位、SOF 包、SetAddress 请求等。PA11/PA12 上立刻就有了真正的 USB 协议波形。换句话说USB “抢走”引脚的最直接表现就是它在引脚上制造了协议电平而你的普通 GPIO 逻辑没法覆盖它。3. “什么都没有做”的USB为什么会输出电平初始化链路上的四个开关3.1 第一个开关GPIO的MODER和AFR配置这一层是我们能在代码里主动控制的。CubeMX 生成代码时如果使能了 USB_OTG_FS它会自动在HAL_PCD_MspInit()里做这样的配置static void HAL_PCD_MspInit(PCD_HandleTypeDef* hpcd) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_USB_OTG_FS_CLK_ENABLE(); /**USB_OTG_FS GPIO Configuration PA11 ------ USB_OTG_FS_DM PA12 ------ USB_OTG_FS_DP */ GPIO_InitStruct.Pin GPIO_PIN_11 | GPIO_PIN_12; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate GPIO_AF10_OTG_FS; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); }这段代码不可谓不“霸道”它把 PA11/PA12 的 MODER 设置为复用功能AFR 设为 AF10。一旦执行从 GPIO 层面看这两个引脚就已经交给 USB 模块了。所以如果你在项目工程文件里加载过 CubeMX 生成的 USB 设备中间件或者从示例工程复制了代码那么哪怕你从来没有调用HAL_PCD_Start()只要MX_USB_DEVICE_Init()被调用过这个开关就已经合上了。在排查时第一步就是去 IDE 的 Register 窗口看GPIOA-AFR[1]或者直接读这个寄存器。PA11 对应 AFR[1] 的 bit[11:8]PA12 对应 bit[15:12]值应该是 0xA也就是十进制 10。3.2 第二个开关外设时钟与收发器电源控制PWRDWN光有 GPIO 复用配置还不够USB 收发器自身也需要工作在“非掉电”状态。在 F4 系列上USB OTG_FS 模块挂在 AHB1 总线上你需要在 RCC 中打开它的时钟__HAL_RCC_USB_OTG_FS_CLK_ENABLE();时钟打开后收发器是否真正工作还看USB_OTG_FS_GCCFG寄存器里的PWRDWNPower Down位。初始状态下这一位通常为 1表示收发器处于掉电状态。HAL 库在HAL_PCD_Init()内部会把 PWRDWN 清零让收发器走出掉电。此时 USB 的数据收发电路才真正“通电”才会作用到 PA11/PA12 引脚上。所以第二个排查点是USB_OTG_FS_GCCFG的 PWRDWN 位是否为 0。如果为 0说明 USB 收发器正在工作即使你不想用它它也在“盯着”引脚。对于带 VDDUSB 独立供电的芯片还要额外确保 VDDUSB 供电正常或者通过HAL_PWREx_EnableUSBRegulator()这类接口打开内部稳压器。如果 USB 模块没有供电收发器自然也就不会工作。3.3 第三个开关内部上拉电阻USB主机识别设备的“钩子”USB 设备要想被主机识别必须让主机看到设备端的上拉。很多 STM32 芯片内部已经集成了这个上拉电阻不需要你在外面再加。例如USB OTG_FS 做全速设备时D 上的内部上拉由寄存器位控制而一些老款型号比如 STM32F103则需要通过软件控制 DP 引脚的上拉或者通过 PA8 引脚外接上拉。只要这个上拉被接通主机就会认为“设备已连接”立刻发起枚举。因此第三个排查点是DP/DM 引脚上是否存在一个 1.5kΩ 左右的上拉源以及这个上拉是由谁控制的。如果是芯片内部上拉且被程序打开了那么即使没有跑任何业务代码枚举也会自动进行。3.4 第四个开关系统Bootloader的DFU检测这一个开关和你的用户代码无关但在实际项目里制造了最多的“灵异事件”。STM32 系统存储区里的出厂 Bootloader在特定启动条件下会检测 USB 主机是否连接。它会占住 PA11/PA12主动完成 USB DFU 枚举并等待上位机下发 DFU 命令。触发条件是 BOOT01、BOOT10或者由 Option Bytes 配置的启动模式此时 CPU 复位后会跳到 System Memory。如果你在这时候插了 USB 线DP/DM 上就会持续出现 USB 枚举流量。这解释了为什么很多新手发现代码明明烧录了一上电 LED 却不闪插上 USB 电脑反而识别出“STM32 Bootloader”。排查方法很简单看 BOOT0 引脚的电平用万用表量一下复位瞬间的启动状态。另外IDE 里如果发现程序计数器停在 0x1FFFxxxx 这种地址多半就是进了系统 Bootloader。4. 复现一次完整排查示波器、寄存器、CubeMX三步定位4.1 第1步用示波器或逻辑分析仪确认波形形态当你怀疑 PA11/PA12 被 USB 抢占不要急着改代码先看波形。把示波器探头夹到 PA11/PA12 和 GND 之间触发方式设为单次或自动观察空闲电平和活动时的波形。普通 GPIO 输出高电平应该稳定在 3.3V输出低电平应该稳定在 0V。如果波形出现高频差分脉冲或者出现长时间的低电平并偶尔有突发包那就要高度怀疑 USB 活动。USB 全速信号速率是 12Mbps建议用 50MHz 以上带宽的示波器带宽不够可能只看到一团模糊的噪声。如果有逻辑分析仪采样率至少在 48MHz 以上否则抓不到完整的包结构。抓包时不要只抓一根线最好把 D 和 D- 一起抓因为 USB 是差分信号两根线是互补的。如果只抓一根线看到的是单端 3.3V 翻转还不够直观。抓完波形后数一下包间隔如果规律地出现大约每毫秒一次的 SOF 包那基本就是 USB 主机在周期性广播帧起始包USB 链路已经被激活。4.2 第2步查GPIO复用寄存器和USB寄存器锁定“谁合上了开关”波形只是表象下一步要从寄存器层面确认。最直接的方法是在调试器里打开 Register 窗口或者用 IAR/Keil 的 Watch 窗口添加表达式GPIOA-MODER GPIOA-AFR[1] RCC-AHB1ENR USB_OTG_FS-GCCFG重点看这几个字段寄存器关键位含义GPIOA-MODERbit[23:22] / bit[25:24]PA11/PA12 模式2b10 表示复用功能GPIOA-AFR[1]bit[11:8] / bit[15:12]0xAAF10说明配给了 USB_OTG_FSRCC-AHB1ENRbit28USB_OTG_FS 时钟是否使能1使能USB_OTG_FS-GCCFGPWRDWN1掉电0正常工作如果 AFR 是 0xA说明是 CubeMX 或者你的初始化代码把引脚切给了 USB。如果 AFR 不是 0xA但波形依然有 USB 活动那就要怀疑是不是 Bootloader 在接管或者外部电路比如 USB PHY 芯片、板载 USB 转串口芯片直接把信号拉到了引脚上。4.3 第3步翻CubeMX配置和启动代码找源头寄存器告诉我们“当前是谁在控制”但要解决问题还得找到“为什么会走到这个状态”。通常有三个入口打开项目里的main.c看是否调用了MX_USB_DEVICE_Init()。CubeMX 在使能 USB 之后即使你的业务功能没有用到 USB它也会在初始化序列里调用这个函数。看usbd_conf.c里的HAL_PCD_MspInit()确认 GPIO 和时钟配置。检查 BOOT0 引脚。如果量产板 BOOT0 被拉高或者用户在设计时预留跳线帽芯片启动后可能进入 DFU Bootloader。这里有个很典型的坑CubeMX 工程从某个示例模板复制而来示例把 USB Device 使能了你自己在这个工程上加了 UART 或 CAN 业务。如果你没留意 CubeMX 界面里 USB_OTG_FS 那一栏它可能一直被勾选着。生成的初始化代码就会默默把 PA11/PA12 切给 USB。这种问题最烦人因为代码看起来“我没有主动调用 USB”但实际上启动阶段立方体生成的MX_USB_DEVICE_Init()已经做完了整个初始化。5. 释放引脚的正确姿势关掉USB外设再恢复复用功能5.1 标准操作流程和HAL库代码如果你的业务根本不需要 USB只是想让 PA11/PA12 安安稳稳做 CAN/SPI/GPIO正确顺序是先停掉 USB 外设、关闭 USB 时钟再配置 GPIO 复用功能。别反过来否则 STM32 的 USB 模拟前端仍可能因为供电和掉电状态未恢复继续影响引脚。下面以 STM32F407 为例写一段标准的“释放引脚”流程。假设工程里已经有 USB 设备句柄hpcd// 1. 如果有 USB 句柄先 DeInit让 PCD 回到初始状态 if (hpcd.Instance ! NULL) { HAL_PCD_DeInit(hpcd); } // 2. 关闭 USB OTG FS 时钟让外设彻底失去时钟源 __HAL_RCC_USB_OTG_FS_CLK_DISABLE(); // 3. 等待几个周期确保内部状态机复位实际延时可放短一点 HAL_Delay(1); // 4. 重新配置 PA11/PA12 为需要的复用功能 // 这里以 CAN1 的 RX/TX 为例AF9 GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); GPIO_InitStruct.Pin GPIO_PIN_11 | GPIO_PIN_12; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate GPIO_AF9_CAN1; HAL_GPIO_Init(GPIOA, GPIO_InitStruct);如果你的工程里没有 USB 句柄可以直接从第 2 步开始。但要注意如果 USB 时钟都没开那 USB 收发器自然不工作第 2 步可以省略。尤其注意第 4 步AFR 一定要改成你实际使用的外设编号不要只改 MODER 到 GPIO 输出模式因为 USB 收发器的模拟通路仍在物理上挂着彻底停止 USB 时钟和掉电状态才是关键。使用 GPIO 输出模式时也同理建议在配置 GPIO 前无论如何都先执行一次__HAL_RCC_USB_OTG_FS_CLK_DISABLE()。这是保证 USB 模拟前端完全失去时钟和唤醒源的有效方法。5.2 共用引脚时的电路级处理跳线、上下拉和USB MUX有的项目确实想同时保留 USB 和 CAN 这两路功能不想二选一。这时候软件层面可以不断切换但容易踩到枚举过程导致设备反复断开重连的坑。更稳妥的做法是从电路设计上做隔离。我比较推荐两种方案板上加 3 针跳线。把 PA11/PA12 通过排针引出一组跳到 USB 座一组跳到 CAN 收发器。用户用哪种功能就插哪组跳线。虽然要多花一个跳线帽的成本但排查问题时的幸福感极高。使用模拟开关或 USB 2:1 MUX。比如 TS3USB221A 这类芯片可以用 GPIO 控制 D/D- 的通路把 USB 差分对切换到不同目标。注意 USB 全速信号是 12Mbps要求模拟开关的带宽足够高导通电阻尽量小否则会影响信号完整性。还有一点容易被忽略如果你用了外部 USB 转串口芯片比如 CH340、FT232它本身是一个 USB Device内部自带 D/D- 上拉切记不要跟 MCU 的 PA11/PA12 直连。很多人的板子上有两个 USB 口其中一个是 USB 转串口芯片另一个是 MCU 原生 USB如果布线时把这两组差分对并在一起就会出现互相干扰、枚举失败的现象。5.3 如何验证释放是否成功释放完引脚不能光看代码逻辑觉得“应该好了”我习惯做三个验证用调试器读USB_OTG_FS-GCCFG确认 PWRDWN1即收发器处于掉电。读RCC-AHB1ENR确认 USB_OTG_FS 时钟位为 0。把 PA11/PA12 配置为 GPIO 输出拉高 3.3V用万用表实测引脚电压。如果第 3 步测出来还是奇怪的电压就要检查外部硬件了比如板子上是否有其他设备的输出直接连到了 PA11/PA12或者调试器本身占用了这些引脚。软件闭环验证通过后再插 USB 线电脑不应该再识别到任何新设备因为设备端已经失去的上拉主机永远不会发现它。6. 少踩坑的经验总结PA11/PA12使用自测清单与几个习惯6.1 一张可以直接抄的自测清单经过这几年做了好几个带 USB 的 STM32 项目我整理了一个“PA11/PA12 被抢自查清单”。每次遇到类似现象按顺序过一遍基本都能定位检查项方法正常状态BOOT0 启动引脚万用表量 BOOT0 电压或看启动配置用户 Flash 模式下应为低电平GPIO MODER查看 GPIOA-MODER应是你要用的功能模式GPIO AFR查看 GPIOA-AFR[1]不应是 AF10除非有意配置 USBUSB 时钟查看 RCC-AHB1ENR 的 bit280关闭USB 收发器掉电查看 USB_OTG_FS-GCCFG 的 PWRDWN1掉电0工作是否为系统 Bootloader查 PC 端是否识别出“STM32 Bootloader”设备不应出现外部硬件干扰看原理图 USB 差分对是否直接并联到 PA11/PA12不共用或已隔离这张清单我打印出来贴在工作台旁边有一次帮朋友排查一块板子两分钟就定位到问题他的 BOOT0 跳线帽插反了芯片一直在 System Bootloader 里跑 DFUPA11/PA12 当然全是 USB 波形。这种问题靠读代码永远读不出来必须从启动条件入手。6.2 我在实际项目中养成的几个习惯最后分享几个代码之外的实操习惯都是踩坑踩出来的经验。第一画板之前先做引脚分配表把 USB、CAN、UART 这类外设的引脚冲突列出来。PA11/PA12 一旦给了 USB就别再安排其它外设否则后续调试会非常痛苦。如果引脚紧张优先在电路板上留跳线而不是靠软件切换。第二CubeMX 里不用的外设一定要显式设成 Disable。很多人觉得“默认未勾选就是没用”其实从示例工程复制配置时USB 可能已经被勾选了却不自知。生成代码后在MX_USB_DEVICE_Init()这个函数名里看到“USB”三个字母就要多留一个心眼。第三启动代码里如果项目完全不用 USB可以在main()最开始就放一行__HAL_RCC_USB_OTG_FS_CLK_DISABLE();这一步等于“关门上锁”即使后面有外设误调用了 USB 初始化时钟不打开很多坑就能提前避开。当然如果后面需要用到 USB再把时钟打开也不迟。第四遇到“引脚奇怪”的问题别急着怀疑编译器、怀疑库函数、怀疑人生。先用示波器看波形再读寄存器。我第一次遇到 PA11/PA12 被 USB 抢占时就是直接在 GPIO 配置上反复改折腾了几个小时后来看了一眼GPIOA-AFR[1]瞬间明白了。寄存器不是洪水猛兽它就是让你快速对线的工具。6.3 回到题目本身一句话回答USB为什么能控制共享的DP/DM引脚把整篇文章压缩成一句话回答 FAQ 的标题USB 能控制共享的 DP/DM 引脚不是因为它有“特权”而是因为 GPIO 的复用开关、USB 外设的时钟/电源使能、内部上拉电阻以及启动模式这四个环节中的任意几个共同作用把引脚的使用权交给了 USB 收发器。收发器一旦开机并退出掉电它就在物理层面驱动了 PA11/PA12普通 GPIO 输出自然压不住。如果你想用这两个引脚做别的事记住这几件事就能避开绝大多数坑检查 BOOT0、检查 AFR、关掉 USB 时钟、确认收发器进入掉电状态。软件层面把这些开关都归位硬件层面做跳线隔离PA11/PA12 就老老实实听你指挥了。
