我估计每个玩 STM32 USB 虚拟串口的人，都经历过这么一出：固件烧进去了，USB 线也插上了，Windows 却给你弹个小气泡“无法识别的 USB 设备”，或者设备管理器里躺着一个黄叹号的“STM32 Virtual ComPort”。这时候很多人第一反应是查固件、查时钟、查 USB 描述符，折腾一宿，结果发现只是驱动没配对。
这篇就把 ST 官方驱动包 STSW-STM32102 的 V1.5.0 版本说透：它到底是干什么的、为什么旧驱动在 Win10/Win11 上经常翻车、正确安装的完整姿势、以及装完以后虚拟串口不能用的排查思路。不管你是刚入门的新手，还是被黄叹号折磨过的老油条，这篇应该都能让你少走几趟弯路。
1. 先弄清楚：驱动到底在忙什么，为什么非得用它
1.1 虚拟 COM 端口和物理串口的区别
很多人第一次接触“虚拟串口”时会有个理解偏差，以为它跟之前用的 CP2102、CH340G 那些 USB 转 TTL 小板子是一回事。其实原理完全不同。
物理串口方案是这样的：STM32 的 UART 经过 TTL 电平转换，从 TXD/RXD 两条线出去，再通过一颗 USB 转串口芯片（比如 CH340G）把 TTL 信号翻译成 USB 协议，PC 端识别成一个 COM 口。这个方案里，USB 协议栈是在 CH340G 芯片里完成的，STM32 本身只负责走 UART。
而虚拟 COM 端口，也就是 USB CDC（Communications Device Class），是把 STM32 芯片内部的 USB 外设当成通信通道。固件里配置好 CDC 类描述符，USB 线一插，主机端枚举到的就是一个“串口设备”，不需要外部 USB 转串口芯片，一条线同时搞定供电和通信。
Windows 本身对 CDC 设备没有内置的通用驱动，所以必须装一个第三方驱动来把它映射成 COM 口。ST 官方出的这套 STSW-STM32102，正是为 STM32 的 USB CDC 设备准备的驱动。
1.2 V1.5.0 解决了什么，和我记忆中的老版本有什么不一样
ST 的虚拟串口驱动其实挺有年头了，很多老项目里还能看到 V1.3.1、V1.4.0 的安装包。但这类老版本在 Windows 10 上非常容易出问题，最常见的就是装完以后设备管理器里依然是黄叹号，或者提示“Windows 无法验证此设备所需的驱动程序的数字签名”。
问题的根源在于驱动签名链。Windows 7 时代签发的驱动证书链，到了 Windows 10/11 上可能不被信任，尤其新版系统要求更严格的 SHA-2 签名。V1.5.0 最大的变化，就是驱动包使用了更新的签名机制，兼容 Windows 7 到 Windows 11，同时提供了 32 位和 64 位两个版本。
我自己的实测感受是：V1.5.0 装起来确实省心。旧版本经常要手动去设备管理器里“更新驱动程序”然后指着路径硬装，V1.5.0 直接运行安装器基本一路下一步就完事，系统会自动把驱动放入系统驱动库，拔插设备后 COM 口就出来了。
1.3 典型的用户画像和适用场景
这套驱动并不是所有 STM32 项目都必须。常见的几个“正好需要”的场景我列一下：
- 用 STM32CubeMX 生成了 USB CDC 工程，想让 PC 端通过串口助手直接看调试信息；
- 做数字电源、温湿度计、鱼缸控制器这类带 USB 设备的小项目，省掉一颗外部 USB 转 TTL 芯片；
- 需要 STM32 和 K210 视觉模块、树莓派之类通信，把虚拟串口用作日志/指令通道；
- 学生做毕设，板载 ST-LINK 的虚拟串口坏了，或者手头板子没有串口芯片，只能用 USB 直接通信。
反过来，如果你用的是 USB 转 TTL 小板子调试，或者板载 ST-LINK 自带的虚拟串口，那这套 STSW-STM32102 就不是给你准备的，别装错方向。
2. 安装前准备：先别急着双击，花两分钟检查这几件事
2.1 正确下载，别从乱七八糟的站点拿包
下载驱动这种事情，一定要认准官方渠道。直接在搜索引擎搜“STSW-STM32102”，很容易点进一些第三方下载站，下载下来是修改过的压缩包，万一带个捆绑软件或者旧版本，后面排错能排到怀疑人生。
推荐两个途径：一个是最传统的 ST 官网搜索 STSW-STM32102，在工具与软件页面下载；另一个是 GitHub 上 ST 的官方仓库，也能找到对应的 VCP 驱动发布记录。下载完先看文件版本，确认是 V1.5.0，因为有些旧教程里的链接可能指向 V1.4.0 甚至更老的包。
解压后的目录结构大致是这样：根目录有安装器或安装说明，驱动本体在 drivers 子目录里区分 x86 和 x64 两个平台，配合的 INF 文件一般是 stmcdc.inf，有的版本还带 Release_Notes.html。初次接触的人不用被这些文件吓到，我们实际只需要用安装器，或者在后手动更新时指到 drivers 目录。
2.2 系统位数和签名策略
装驱动之前，先看一眼自己的 Windows 是多少位的。按下 Win+R，输入msinfo32，在“系统类型”里能看到“基于 x64 的电脑”还是“基于 x86 的电脑”。64 位系统用 x64 目录，32 位系统用 x86 目录。
Win7 用户要额外注意一个点：V1.5.0 的驱动使用了 SHA-2 签名，如果你的 Win7 没有安装相应的 SHA-2 补丁，系统会提示签名验证失败。解决办法是先更新一下系统补丁，把 KB4474419、KB4490628 这一类 SHA-2 支持补丁装上，再装驱动。Win10 和 Win11 基本没这个问题，默认支持。
另外提一下安全启动。UEFI 下开启 Secure Boot 一般不会影响驱动安装，因为 V1.5.0 是正规签名驱动。真正影响签名的是你自己改过 INF 文件，这个后面会单独讲。
2.3 固件侧确认枚举的前提
驱动是 PC 端的事，但虚拟串口能不能成功枚举，固件侧的配合很关键。如果你按网上例程做了个 USB CDC 设备，插上电脑却一点反应都没有，甚至设备管理器完全没有任何新设备弹出，先不要怀疑驱动，大概率是 USB 枚举就没成功。
STM32 的 USB 枚举成功需要几个硬性条件。第一是供电稳定，USB 口供电不足或者板子上的 USB 电源滤波太差，枚举会中途失败。第二是时钟正确，特别是 F1 系列，必须确保 USB 外设使用的时钟是 48MHz，常用做法是从 PLL 分出 48MHz 给 USB 预分频器。第三是 D+/D- 走线正常，有的板子需要外部上拉电阻，有的可以启用芯片内部上拉。
我自己调试时有个习惯：先用 STM32CubeMX 生成一个最小的 CDC 工程，不写任何业务逻辑，烧进去以后只插 USB 线，看电脑能不能识别。这一步能过，再往后加代码。如果连最小工程都枚举不了，那问题就在硬件或时钟配置上，跟驱动没关系。
提示：检查枚举是否成功的动作，建议插上 USB 线以后盯着设备管理器看几秒，看有没有设备列表刷新。拔插的瞬间变化比“是否报错”更能说明问题。
3. 安装实操：从插上设备到看到 COM 口
3.1 先让 Windows 看到设备
把烧录好 CDC 固件的板子插上 USB，等待几秒，然后打开设备管理器。正常的识别结果大体上有几种表现：
- 显示为“STM32 Virtual ComPort”带黄叹号，说明设备枚举成功，只差驱动；
- 显示为“USB 串行设备”，说明系统已经用了微软的 usbser.sys 通用驱动，但可能没稳定识别；
- 显示为“未知设备”或者“无法识别的 USB 设备”，说明枚举阶段可能就有问题。
这时先不要急着点“更新驱动”，先判断设备到底认没认出来。如果完全没出现在设备管理器里，问题在硬件或固件，驱动帮不上忙。
3.2 自动安装：运行 dpinst 安装器
V1.5.0 包内带了一个安装器，64 位系统运行 dpinst_amd64.exe，32 位运行 dpinst_x86.exe。这个安装器本质上是 Microsoft 的 DPInst 工具，它的作用不只是把驱动复制到系统目录，而是将驱动包安装进系统的“驱动存储区”，Proc 后续拔插设备时系统自动匹配。
运行过程很傻瓜，点击下一步，等待它提示安装完成即可。安装完成后把 USB 设备重新插拔一次，或者等待几秒钟让系统重新扫描硬件。正常情况下，设备管理器里的“端口（COM 和 LPT）”下面会出现类似“STMicroelectronics Virtual COM Port (COMx)”的条目。
为什么推荐先自动安装而不是手动指定 INF？因为 DPInst 会走系统的驱动签名验证流程，保证安装后的驱动可靠。手动指定 INF 时，如果目录路径带空格或者 INF 文件被改动过，很容易蹦出签名相关的报错。
3.3 手动更新驱动的标准姿势
如果自动安装失败，或者设备管理器里已经有一个黄叹号的设备，你需要走手动更新的路子。操作路径是：
- 在设备管理器里右键这个设备，选择“更新驱动程序”；
- 选择“浏览我的电脑以查找驱动程序”；
- 点“浏览”，选中解压后的 VCP_V1.5.0 驱动目录，注意勾选“包括子文件夹”；
- 点“下一步”，系统开始搜索并安装匹配的驱动；
- 如果弹窗提示“是否安装此设备驱动程序”，选择“安装”。
这个流程和装任何标准 Windows 驱动都一样，唯一容易踩坑的是目录选错。有些人直接把整个压缩包解压后的根目录指过去，结果系统找不到 INF 文件，报“找不到驱动程序”。记住，INF 文件一般在 drivers 子目录里，要么把路径指到 drivers，要么让系统子文件夹里自动搜索。
3.4 用串口助手验证虚拟串口真正工作
装好驱动不代表万事大吉，建议立刻用串口助手验证一遍。打开你自己习惯的串口工具，选择新出现的 COMx，波特率随便填，填 115200 也好填 9600 也罢。
这里有个新手容易困惑的点：USB CDC 虚拟串口的波特率，并不是真的用于决定物理传输速率，USB 全速/高速传输本身有自己的带宽调度机制。波特率只作为一个约定值传给驱动和固件，实际通信速率由 USB 协议决定，所以波特率不会像物理 UART 那样影响收发正确性。
验证方案有两个。一个是在固件里写一个收到啥回啥的 echo，串口助手发字符串能看到回显。另一个是直接让固件上电发送一行启动信息，串口助手能收下来。两个都过，这条链路才算真正跑通。
4. 固件端的配合：驱动装上没反应，先从这几个地方查
4.1 USB CDC 工程初始化的最小清单
哪怕驱动装得再完美，固件侧 USB 枚举失败，设备照样不出现 COM 口。我建议所有从零开始做虚拟串口的人都按这份最小清单检查一遍。
用 STM32CubeMX 打开工程项目，确认 USB 相关配置：如果芯片带 USB OTG FS，通常要选 Device_Only 模式；在中间件 USB_DEVICE 里选择 Communication Device Class（Virtual Port Com），而不是 Mass Storage Class 或其它。时钟配置页里，保证 USB 时钟源是 48MHz，STM32F4 系列一般从 PLLQ 输出，F1 系列要注意存在独立的 USB 预分频器，必须配置正确。
生成的初始化代码中，MX_USB_DEVICE_Init()要在系统时钟初始化完成后调用，不能把它丢在某个边角地方被绕过去。如果用了低功耗模式，还要检查 USB 外设是否会在休眠时挂掉。
4.2 printf 重定向到虚拟串口的正确姿势
很多人的调试思路是：以前用物理串口，printf 重定向到 UART，现在换了虚拟串口，直接把fputc重写到 CDC 发送就行。理论上没错，但实际跑起来会发现两个大坑：发送卡顿、数据丢失。
先看最简单的重定向写法：
#include <stdio.h> int fputc(int ch, FILE *f) { uint8_t data = (uint8_t)ch; CDC_Transmit_FS(&data, 1); return ch; }这个写法在轻负载下能用，但一旦 printf 的频率上来，就会发现数据丢失严重。原因在于 ST 库的CDC_Transmit_FS()是非阻塞发送，如果上一次数据还没发完，再调用就会返回USBD_BUSY，而你的 fputc 直接把这个返回值忽略了，数据自然就丢了。
更稳的做法是带忙等待：
int fputc(int ch, FILE *f) { uint8_t data = (uint8_t)ch; while (CDC_Transmit_FS(&data, 1) == USBD_BUSY); return ch; }注意这样会让 CPU 死等 USB 外设发送完成，在高速打印时效率一般，但至少不会丢字节。如果你想兼顾效率和稳定，可以考虑在 USB 发送完成中断里挂一个标志，fputc 里轮询这个标志。这套思路和物理 UART 的 busy-wait 发送很相似，只不过多了一层 USB 协议栈的交互。
4.3 别忽略 DTR/RTS 和回环接收
装好驱动以后，如果你用的串口助手默认勾选了“打开串口时置 DTR”，而板子的硬件设计师又恰好把 DTR 信号接到了 MCU 的复位脚上，那么每次你打开串口，STM32 就会复位一次。这个问题很隐蔽，表现形式是“我一连接串口，设备重启了”。排查方法是换一个不控制 DTR 的串口工具，或者检查板子原理图看 USB CDC 的 DTR/RTS 有没有连到 NRST。
另外，很多 STM32 的 CDC 例程里，接收回调CDC_Receive_FS()只在第一次调用时生效。如果程序里没有在回调结束前再次调用USBD_CDC_ReceivePacket()，那么设备只能接收第一包数据，后面 PC 发的所有内容都石沉大海。这是新手最容易忽视的问题，一旦出现“设备能发但收不到指令”的情况，优先检查这里。
5. 常见问题与排查技巧实录
5.1 安装后始终是黄色感叹号，问题出在哪
黄叹号是本话题里最多的求助，常见原因和对应做法我整理成一个速查表：
| 现象 | 可能原因 | 处理方法 |
|---|---|---|
| 驱动装完设备还是感叹号 | 旧版 VCP 驱动残留，导致新旧驱动冲突 | 使用 pnputil 删除旧驱动包后重装 |
| 安装提示找不到 INF | 指定目录选错，或 INF 被改名 | 指向 drivers 子目录并勾选“包括子文件夹” |
| 设备显示代码 31 | 系统驱动存储区损坏或权限异常 | 管理员权限运行安装器，更新 Windows 补丁 |
| 装完以后另一台机器不识别 | 只装了安装器没等驱动存储区生效 | 拔插设备或重启后再看设备管理器 |
| 旧驱动没卸干净 | 之前手动指定过别的 INF | pnputil /delete-driver 指定旧包名卸载 |
pnputil是个非常好用的系统命令，可以查看所有第三方驱动包。
pnputil /enum-drivers找到和 stmcdc 或 STMicroelectronics 相关的驱动包名后，用以下命令删除：
pnputil /delete-driver oemXX.inf注意这个命令需要管理员权限。清理完再重装 V1.5.0，黄叹号的问题大多数能解决。
5.2 代码 31、代码 10 到底在说什么
设备管理器里设备属性中，状态栏显示“Windows 无法加载这个设备所需的驱动程序。代码 31”或者“无法启动该设备。代码 10”。这两个错误码的意思有区别。
代码 31 侧重在驱动加载阶段，通常意味着系统里存在无效驱动记录，或者驱动与当前系统不兼容。优先考虑卸载重装、清理驱动残留、检查是不是装错成了 x86 驱动。
代码 10 则在驱动的启动阶段。USB 设备出现代码 10，常见的原因包括：主板 USB 口供电不足、延长线或转接头质量差、USB 描述符读取异常、固件在枚举过程中崩了。我遇到过最离谱的一次，是板子上 USB 的 D+ 上拉电阻虚焊，导致设备能枚举一半，然后消失，设备管理器里一会是未知设备一会是代码 10。
排查代码 10 的思路是：先换根短 USB 线直连电脑主板后置口，确认不是线材和供电。再用 STM32CubeProgrammer 连一下板子的 ST-LINK 或者串口，确认固件还在运行。如果固件好好的，那就查 USB 硬件电路。
5.3 驱动签名验证失败怎么处理
Win10/Win11 下，系统弹出“Windows 无法验证此设备所需的驱动程序的数字签名”时，先不要走“禁用驱动签名强制”这条路。那个办法只适合临时测试，重启一次就失效，而且长期处于禁用签名状态会有安全风险。
正确的做法是确认三件事。第一，你的安装包是不是从官方渠道拿的原版，签名是否被破坏。第二，系统时间和证书有效性，系统时间不对会导致证书链校验失败。第三，驱动版本是不是太老，如果是 V1.3.1 这类老包在 Win10/11 上确实容易触发签名问题，直接换 V1.5.0。
如果你确实在开发阶段需要测试一个改过 VID/PID 的 INF，临时用一下测试模式或者禁用签名验证也可以理解，但千万别把这个状态带到生产环境。正经的产品驱动，要么用官方 VID/PID 走官方驱动，要么自己申请 WHQL 签名，否则分发出去就是给自己找麻烦。
5.4 板载 ST-LINK 虚拟串口和 STM32 虚拟串口分不清
现在的 NUCLEO、Disco 开发板上，通常有两个能出串口的地方。一个来自板载 ST-LINK/ST-LINK/V3 调试器的虚拟串口，对应 PC 端设备管理器的“STMicroelectronics STLink Virtual COM Port”。另一个来自 STM32 芯片自身的 USB CDC，对应“STMicroelectronics Virtual COM Port”。
这两个设备使用不同的驱动包。ST-LINK 虚拟串口的驱动由 ST-LINK 驱动包提供，通常叫 STSW-LINK009，而不是 STSW-STM32102。很多时候有人把 ST-LINK 的虚拟串口识别不出来，错误地去安装了 VCP 驱动，结果当然是没用。
区分方法很简单：插上开发板以后，看设备管理器里出现的设备名字。带 STLink 字样的就是 ST-LINK 虚拟串口，不要用 STSW-STM32102 去装。板子自带的 STM32 USB CDC 口，如果命名显示 STM32 Virtual ComPort，那才是本文这套 VCP 驱动的服务对象。
5.5 最容易被忽略的“拔插时机”
还有一个细节，我每次讲课或者答疑时都会强调：驱动安装完成后，别急着打开串口助手，先拔掉 USB 线，等两秒，再插回去。原因很简单，很多 USB 设备在驱动变更后并不会立刻重新枚举，Windows 会沿用旧的错误状态。拔插一次，让设备重新走一遍枚举流程，COM 口很可能就正常出现了。
如果手头设备不方便拔插，也可以在设备管理器里右键设备，选“禁用设备”再“启用设备”，效果类似，但不如物理拔插干净。
6. 我在实际项目里的几点体会
6.1 为什么我一直推荐官方驱动
用过各种各样的 USB 串口驱动之后，我的结论是：STM32 的虚拟串口调试，能上官方驱动就上官方驱动。原因不只是稳，更重要的是它少折腾。网上有些非官方驱动也能让设备出 COM 口，但签名、兼容性、杀毒误报都是潜在坑。我自己就见过同事为了省事装了个第三方驱动，结果 Windows 更新以后驱动被系统自动回滚，设备直接失联，排查了一下午。
V1.5.0 在 Win10/11 上的表现基本让人满意，唯一的遗憾是配套文档不够细，很多细节要靠自己试，所以才有这篇总结。
6.2 多板卡调试时的 COM 口管理建议
同时调试三四块板子时，虚拟串口的 COM 口号会让人抓狂。每次插拔顺序不同，COM 号就会漂移，你永远不知道当前接的是哪个设备。
我个人的习惯是，在固件里加入设备标识打印，上电后第一行输出就是固件版本号和板卡编号。这样不管 COM 口怎么变，打开串口助手一看第一行就能确认接的是哪块板子。
另外，Windows 的设备管理器里也可以把某个 USB 口固定到特定 COM 号。右键 COM 口属性，点“端口设置”-“高级”，里面可以设置 COM 端口号。固定以后，只要插入同一个 USB 口，系统就用这个 COM 号，省去来回看的麻烦。
6.3 虚拟串口的局限，别把它当高速传输通道
最后说一句可能会被一些人忽略的话：虚拟串口适合调试和控制，但不适合做高可靠的大数据链路。USB CDC 本身有一套流控机制，但很多 STM32 的 CDC 固件实现并不完善，缓冲区溢出就会丢数据。真需要高速可靠双向传输，应该考虑 USB 的批量传输方式，也就是自定义 HID 或者 WinUSB，或者干脆上以太网接口。
最近看到有人在 STM32 上做车载以太网调试，方案里依然保留了一个虚拟串口做日志输出。这种组合我很推荐，虚拟串口只用来打印关键节点，真正的业务数据走以太网，互不干扰，排查问题的时候效率会高很多。
6.4 一个小技巧：连接后先发版本号
每次虚拟串口连通以后，第一个动作不是收发业务数据，而是把固件版本号、编译时间、当前运行的模式发出来。这个习惯帮我省了大量排查时间。比如有时候对方报告“连不上”，我一看日志是固件版本太旧，根本不需要在驱动层面折腾。
装驱动这件事，说到底就是个一次性工作，真正决定你使用体验的，往往是后续的排查手段和良好习惯。希望这篇能把 STSW-STM32102 V1.5.0 的门道讲透，下次再看到那个黄叹号，你知道该从哪下手。
