简介：面向 STM32 USB 开发者的组合设备工程包，基于 STM32F107 演示如何利用 CubeMX 配置 HID+CDC 双类 USB 设备，解决同时提供人机交互与虚拟串口通信时的工程搭建难题。工程包含完整源码、HAL 库初始化代码、USB 设备类库与 Keil MDK 工程配置，从端点选择、中断优先级到应用层收发都有现成代码可对照，可直接打开编译学习。压缩包共 1023 个文件，约 28.72MB，主体为 570 个 C 源文件与 255 个头文件，另含启动汇编、链接脚本、MAP/LST 映射列表、HEX/AXF 可执行镜像等，便于查看编译流程、内存映射与最终固件。已有 3129 人学习下载。对需要理解 USB 端点分配、HID 与 CDC 中断服务例程区分、HAL 库调用流程的开发者，这份资源能提供从工程配置到应用层数据收发的完整代码参照，尤其适合物联网、数据采集等场景下的二次开发与排错，也有助于理解 USB 枚举、类请求、端点回调等底层细节。
1. STM32 USB 组合设备：从单设备到 HID+CDC 一次搞通
一个 USB 设备插上电脑，既想当键盘/鼠标用，又想虚拟出一个串口来通信——这就是组合设备（Composite Device）的典型需求。很多开发者卡在这一步：单独调 HID 一切正常，单独调 CDC 也没问题，一旦把两个设备描述符合并到一起，电脑要么只认其中一个，要么整个设备直接枚举失败。这篇笔记会把 STM32 的 USB 协议栈里 HID 和 CDC 组合的配置过程完整拆开：从描述符怎么排列、端点怎么分配，到中断回调怎么共用一个句柄，最后落到一套可以直接修改使用的代码结构。适合已经被 USB 基础枚举折腾过、但还没动过组合设备的开发者，也适合准备从零开始做双模键盘、USB 转串口工具的人。
2. 组合设备的底层逻辑:枚举流程、配置描述符与设备框架
2.1 为什么单一类设备不够用，组合设备解决了什么
在讲描述符之前，先明确一个问题：为什么不能直接在主循环里同时轮询 HID 和 CDC 的逻辑，非得在 USB 协议层面做组合？
USB 是一个主从架构的总线，所有通信由主机发起。设备端的逻辑是：主机枚举设备时读取设备的描述符，根据描述符里的接口信息加载对应的驱动程序。如果你在设备端单纯把 HID 的中断端点和 CDC 的数据端点都初始化了，但配置描述符里没有正确地描述这两个接口，主机只会在枚举过程中看到一份无效的配置描述符，然后报错“未知 USB 设备”。
组合设备的本质是：在同一个配置描述符里，按顺序排列多个接口集合（Interface Association），每个集合对应一个独立的设备类。主机枚举时看到几个不同的接口集合，就会加载几份不同的驱动，于是设备在电脑上同时呈现出“键盘”和“串口”两个功能。
这里还有一个容易混淆的概念：复合设备（Composite Device）和组合设备（Composite Device）在不同厂商文档里的叫法不同，但在 STM32 的 USB 协议栈代码里，通常指的就是一个配置描述符包含多个接口。另外还有一个词叫“多功能设备”（Multi-Function Device），Windows 会把一个配置里的多个接口识别为多个独立功能节点，实际效果与组合设备等同，只是叫法不同。
2.2 枚举流程回顾:主机如何一步步识别你的设备
USB 设备插上后，主机会按固定的顺序发起标准请求。设备固件只要在这个流程里正确响应，枚举就能通过。一个完整的枚举流程大致如下：
- 主机发送复位信号，设备地址恢复为 0
- 主机读取设备描述符的前 8 字节（只取前 8 字节，后续可能再读全量）
- 主机发送 Set Address 请求，给设备分配地址
- 主机用新地址再次读取设备描述符的全量数据
- 主机读取配置描述符，包括所有接口描述符和端点描述符
- 如果设备类需要，主机读取字符串描述符或类特殊描述符（HID 描述符、CDC 功能描述符）
- 主机选择合适的配置，发送 Set Configuration 请求，设备进入配置状态
在组合设备场景下，第 5 步是核心。配置描述符是一段连续的内存，它的结构是：配置描述符 + 接口描述符 + 端点描述符 + 类特殊描述符 + 下一个接口描述符 + ……。主机一次把整段配置描述符读完，解析里面的结构。
常见的问题是：STM32 标准外设库里的 usbd_desc.c 和 usbd_conf.c 文件都提供了默认的处理流程，但组合设备需要你自己重写一部分回调函数。默认代码往往只针对单一设备类，接口数、端点数和配置描述符的大小都是写死的，直接改成组合设备时很容易出现缓冲区长度不够、描述符索引错位的问题。
2.3 配置描述符内存布局:接口关联描述符(IAD)是关键
组合设备的配置描述符里有一个关键结构：接口关联描述符（Interface Association Descriptor, IAD），通常简写为 IAD。它并不是所有 USB 设备都需要，只有当一个接口集合包含多个接口时才需要。
IAD 的作用是告诉主机：接下来的几个接口属于同一个设备功能。比如 CDC 类设备需要两个接口——一个用于通信控制（包括 CDC 控制端点），一个用于数据收发。没有 IAD 的时候，主机可能会把这两个接口当作两个独立功能处理，导致驱动加载异常。
在 HID+CDC 组合设备里，配置描述符的推荐排列顺序是：
- 配置描述符（9 字节）
- IAD 描述符（8 字节），声明第一组接口属于 CDC
- 接口描述符，CDC 通信控制接口（Interface 0，class 0x02）
- CDC 类特殊描述符（功能描述符，Header/ACM/Union）
- 端点描述符，CDC 控制端点（方向通常为 IN）
- 接口描述符，CDC 数据接口（Interface 1，class 0x0A）
- 端点描述符，CDC 数据端点 OUT
- 端点描述符，CDC 数据端点 IN
- HID 接口描述符（Interface 2，class 0x03）
- HID 类特殊描述符
- 端点描述符，HID 中断端点 IN
有些实现会把 HID 接口放在前面，CDC 放在后面，效果等同，但注意 IAD 必须紧贴接口描述符且与所属接口一一对应。接口号必须连续且从 0 开始递增，HID 接口号用 2 没问题，但接口总数量必须正确填写在配置描述符的 bNumInterfaces 字段。
这段描述符的排列方式直接决定了主机端驱动的加载行为。如果 IAD 里的 bFirstInterface 和 bInterfaceCount 对不上，或者 CDC 的两个接口之间插入了一个 HID 接口，就会出现“设备枚举成功但功能错乱”的情况——比如串口号出来了，但键盘没反应，或者反过来。
3. 把 HID 和 CDC 揉进一个设备:应用层驱动的组织方式
3.1 独立设备的描述符与端点分配逻辑
在动手改组合设备之前，先把独立 HID 设备和独立 CDC 设备吃完透。这两个设备类的描述符结构有着本质差异：HID 设备只需要一个接口、一个中断端点；CDC 设备需要两个接口加一个中断端点加两个批量端点。
两者的端点分配差异是我认为整个组合设备配置里最容易出错的地方。HID 类设备规范要求中断端点，且最大包长是 64 字节（全速设备）；CDC 设备的数据传输用的是批量端点，方向一进一出，再加上一个可选的中断端点用于通知线路状态。所以一个 HID+CDC 组合设备最少需要 5 个端点：CDC 的 IN 批量端点 + OUT 批量端点 + CDC 的中断端点 + HID 的中断端点，再加上控制端点 0。
STM32 USB 全速设备（比如 F103 系列）的端点数量是固定的，通常有 8 个端点块，编号 0 到 7。而高速设备（比如 F4 系列带内置 PHY 的型号）有 4 个端点块。如果你用的芯片只有 4 个端点，那么把 CDC 和 HID 组合起来之后，端点号必须紧凑分配。
端点分配建议：
- 端点 0：控制传输（所有 USB 设备都要有）
- 端点 1：CDC 批量 IN（设备到主机，数据上行）
- 端点 2：CDC 批量 OUT（主机到设备，数据下行）
- 端点 3：CDC 中断 IN（通知主机线路状态）
- 端点 4：HID 中断 IN（键盘/鼠标数据上行）
把 CDC 和 HID 的端点错开编号，而不是共用一个端点号。原因很简单：端点号的分配是由设备描述符里的端点描述符决定的，如果你把 CDC 的 IN 端点和 HID 的 IN 端点都写成端点 1，主机只会在设备描述符里看到“重复的端点地址”，直接判定描述符无效。
3.2 接口数量与类特殊描述符的编排要点
很多开发者组合 HID+CDC 时只盯着端点，忽略了接口数量的计算。CDC 类设备需要两个接口（通信控制接口和数据接口），HID 只需要一个接口。三个接口加起来，接口总数是 3，不是 2。这个数字填错，枚举会直接失败。
接口号从 0 开始分配。注意 HID 接口放在第三个位置，接口号就是 2，但它的接口描述符里并没有“接口号越大优先级越高”的规则，驱动加载顺序完全看接口在配置描述符里的物理顺序，顺序越靠前的主机识别越早。
另一个容易忽略的是 CDC 类特殊描述符。CDC 设备的通信控制接口下必须跟三段功能描述符：Header（头描述符）、ACM（抽象控制模型）、Union（联合描述符）。这三段缺一不可——尤其 Union 描述符，它把通信控制接口和数据接口绑定为一组，没有它，主机不知道这两个接口是一个功能的两半，驱动加载会失败或乱序。
而 HID 类设备的类特殊描述符是 HID 描述符，它里面包括一个报告描述符的长度字段。这个长度字段必须和实际发给主机的 HID 报告描述符长度一致。很多人改了报告描述符但忘记同步更新 HID 描述符里的 wReportDescriptorLength 字段，结果主机枚举时报告描述符读不全，HID 功能直接失效。
3.3 中断回调与数据直通：双设备共享一个 USB 句柄
USB 协议栈在 STM32 里通常用一个全局结构体保存所有端点的状态。组合设备的固件处理方式是：初始化协议栈时注册一个完整的 USB 设备实例，但中断服务函数里，通过传输的端点号来区分是哪个设备类的事件。
以 STM32F1 的标准外设库为例，USB 中断服务函数内通常会遍历所有端点并检查事件标志。组合设备场景下，一般写法是：
void USB_Istr(void) { // 检查传输完成事件：wIstr 是标准外设库里的中断状态寄存器值 if (wIstr & USB_ISTR_TRANSFER) { // 根据当前传输端点号分发到对应设备类的回调 uint32_t ep = GetEPNum(); // 读取端点号 if (ep == CDC_DATA_IN_EP || ep == CDC_DATA_OUT_EP) { CDC_DataRx_Handler(ep); } else if (ep == HID_IN_EP) { HID_Send_Handler(ep); } } }GetEPNum()读取 USB 端点号寄存器，标准外设库里的宏定义通常为_GetEPNum()。CDC 的数据端点是批量传输，HID 是中断传输，两种传输在中断标志上的判断逻辑是一致的，都是检查传输完成位，区别只在回调函数内部处理的数据格式和端点方向。
我一般这样组织回调：CDC 的数据收发回调里只做环形缓冲区的读写，把数据交给协议层；HID 的回调里只做发送状态位的清理，不做数据解析。相互之间不直接调用，避免重入问题。为什么这么设计——USB 中断的优先级通常设置为最高，如果在回调里处理耗时逻辑，串口接收的背压会直接导致数据覆盖，特别是高波特率场景。
4. STM32 组合设备移植实战:从配置代码到中断收发的完整修改清单
4.1 描述符数组构建:逐个字节对齐 IAD、HID 和 CDC
组合设备的移植修改点集中在 usbd_desc.c、usbd_conf.c 和 usbd_ctlreq.c 这几个文件。描述符数组通常定义在 usbd_desc.c 里，组合设备需要把 HID 和 CDC 的描述符合并到同一段数组里。
一个可用的配置描述符数组的结构如下（以全速设备为例）：
// 组合设备配置描述符:CDC(HID) 整体拼接 uint8_t USBD_ConfigDescriptor[] = { // 配置描述符 0x09, // bLength: 配置描述符长度 9 USB_DESC_TYPE_CONFIGURATION,// bDescriptorType: 0x02 LOBYTE(CFG_TOTAL_LEN), // wTotalLength 低字节 HIBYTE(CFG_TOTAL_LEN), // wTotalLength 高字节 0x03, // bNumInterfaces: 接口总数 = CDC 2个 + HID 1个 0x01, // bConfigurationValue 0x00, // iConfiguration 0xC0, // bmAttributes: 自供电 0x32, // bMaxPower: 100mA // IAD 描述符:把 CDC 的接口 0 和接口 1 关联起来 0x08, // bLength: IAD 长度 8 0x0B, // bDescriptorType: 0x0B 0x00, // bFirstInterface: 起始接口号为 0 0x02, // bInterfaceCount: 共用 2 个接口 0x02, // bFunctionClass: CDC 通信类 0x02, // bFunctionSubClass: ACM 子类 0x00, // bFunctionProtocol 0x00, // iFunction // 接口描述符 0:CDC 通信控制接口 0x09, 0x04, 0x00, 0x00, 0x01, 0x02, 0x02, 0x01, 0x00, // CDC 功能描述符:Header(5) + ACM(4) + Union(5) 0x05, 0x24, 0x00, 0x10, 0x01, 0x04, 0x24, 0x02, 0x02, 0x05, 0x24, 0x06, 0x00, 0x01, // 端点描述符:CDC 控制端点(中断 IN) 0x07, 0x05, 0x83, 0x03, 0x08, 0x00, 0x08, // 接口描述符 1:CDC 数据接口 0x09, 0x04, 0x01, 0x00, 0x02, 0x0A, 0x00, 0x00, 0x00, // 端点描述符:CDC 数据 IN + 数据 OUT 0x07, 0x05, 0x81, 0x02, 0x40, 0x00, 0x00, 0x07, 0x05, 0x01, 0x02, 0x40, 0x00, 0x00, // 接口描述符 2:HID 接口 0x09, 0x04, 0x02, 0x00, 0x01, 0x03, 0x00, 0x00, 0x00, // HID 描述符:9 字节,含报告描述符长度 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, HID_REPORT_DESC_SIZE_LO, HID_REPORT_DESC_SIZE_HI, // 端点描述符:HID 中断 IN 0x07, 0x05, 0x84, 0x03, 0x40, 0x00, 0x0A, };这里有个容易踩的坑：bMaxPower字段的单位是 2mA，写成 0x32 表示 100mA。如果你把 USB 枚举的硬件拉起来后主机报“超过电流限制”，大概率是这里配置超过实际接线的供电能力。
另外注意 HID 描述符部分最后两个字节HID_REPORT_DESC_SIZE_LO和HID_REPORT_DESC_SIZE_HI，需要对应你实际的报告描述符数组长度。这种写法用宏在头文件里定义，改报告描述符时只改宏的值，不容易出现长度不同步的问题。
4.2 协议栈初始化:双设备注册顺序与回调绑定
在 usbd_conf.c 或主循环的初始化代码中，需要完成协议栈初始化、设备类注册和端点分配三个动作，而且顺序不能乱。
以 STM32CubeMX 生成的代码为参考，手动补全组合设备时的初始化逻辑：
void USB_Composite_Init(void) { // 1. 初始化底层硬件和 USB 协议栈 USBD_Init(&hUsbDeviceFS, &USB_Desc, DEVICE_FS); // 2. 注册 CDC 类回调,注意顺序:先注册 CDC 再注册 HID USBD_RegisterClass(&hUsbDeviceFS, &USBD_CDC); // 3. 注册 HID 类回调 USBD_RegisterClass(&hUsbDeviceFS, &USBD_HID); // 4. 启动 USB 设备 USBD_Start(&hUsbDeviceFS); }注册顺序为什么有讲究——USB 协议栈内部维护一个类回调链表，主机发送 SET_CONFIGURATION 请求时，协议栈按注册顺序遍历每个类回调的 Setup 处理函数。而 IAD 在描述符里声明了 CDC 接口集合，主机不会跨越 IAD 边界去匹配设备类。但协议栈的类回调在检查接口号时，如果顺序错位，可能会出现 HID 的回调先截获了 CDC 接口的控制请求，导致 CDC 的 SET_LINE_CODING 请求无人响应。
// 端点最大包长的设置: // 全速设备 CDC 批量端点最大包长建议 0x40(64 字节) // 全速设备 HID 中断端点最大包长建议 0x40(64 字节)我常用的排查方式是初始化完成后，用 USB 分析仪或逻辑分析仪抓取枚举阶段的全部控制传输内容，对照标准描述符结构逐字节检查。如果没有硬件抓包工具，可以用 Windows 的 USBView 或 Linux 的 lsusb -v 查看主机解析出来的描述符结构，这里的输出和固件里的数组是一一对应的。
4.3 数据收发内联:CDC 环形队列与 HID 发送状态机
CDC 的收发逻辑一般用双环形队列实现，一个 RX 队列存放设备接收到的主机数据，一个 TX 队列存放设备待发送的数据。HID 的发送逻辑更简单，就是写完报告描述符对应的字节后，触发一次中断传输。
下面是两个核心收发函数的参考写法：
// CDC 数据发送:把应用层数据写入 CDC FIFO 并触发端点发送 uint8_t CDC_Transmit(uint8_t* data, uint16_t len) { // 检查端点是否忙 if (USBD_CDC_IsTxReady(&hUsbDeviceFS) != 1) { // 上一包还没发完,入队等待 ringbuf_write(&tx_ring, data, len); return 0; } // 端点空闲,直接写入端点缓冲 USBD_CDC_SetTxBuffer(&hUsbDeviceFS, data, len); USBD_CDC_TransmitPacket(&hUsbDeviceFS); return 1; } // HID 发送:发送 4 字节键盘报告(修饰键+保留+2个按键键值) uint8_t HID_SendKeyReport(uint8_t mod, uint8_t keycode1, uint8_t keycode2) { static uint8_t report[4]; report[0] = mod; report[1] = 0x00; report[2] = keycode1; report[3] = keycode2; // 忙则丢弃本次数据(键盘事件不可重发) if (USBD_HID_IsReady(&hUsbDeviceFS) != 1) { return 0; } USBD_HID_SendReport(&hUsbDeviceFS, report, 4); return 1; }CDC 的发送失败处理我一般做“丢包不如排队”的策略，因为串口的数据连续性比实时性重要；而 HID 的发送失败处理则是直接丢弃，因为键盘输入的事件数据是瞬时的，重发一个旧按键反而会造成按键重复输入。
端点缓冲区的容量也值得留意。F103 的 USB 端点缓冲区总共 512 字节，CDC 的虚拟串口设置波特率 115200 时不带来压力，但如果你在 HID 报告里加了额外的功能（比如灯光控制、媒体按键），报告长度从 4 字节增加到 8 字节，HID 的端点缓冲区占用会翻倍，可能导致 CDC 端点分配到的缓冲不足。
4.4 状态同步:枚举成功指示与双功能失联问题
组合设备还有一个容易被忽略的细节：设备端的标准请求处理函数需要同时响应两类设备类的类特定请求。
HID 类的标准请求有 GET_REPORT、SET_REPORT、GET_IDLE、SET_IDLE 等；CDC 类的标准请求有 SET_LINE_CODING、GET_LINE_CODING、SET_CONTROL_LINE_STATE。协议栈里通常用 Setup 回调来分发这些请求。你在写回调时要注意一个细节：协议栈的标准请求回调函数里，如果没有匹配到请求，需要返回错误状态而不是静默忽略。
这个细节的坑在于：比如 HID 的 SET_IDLE 请求被错误地交给了 CDC 的 Setup 回调处理，CDC 回调不认识这个请求，返回了成功但没有任何实际动作，主机就认为 SET_IDLE 已完成。后续 HID 设备会一直处于空闲状态，按键数据发送频率被无限降低，表现为按键偶尔失灵。所以在 Setup 回调里，建议这样处理：
static int8_t Composite_Setup(USBD_HandleTypeDef *pdev, USBD_SetupReqTypedef *req) { // 根据接口号分发请求:接口 0/1 归 CDC,接口 2 归 HID if ((req->wIndex & 0xFF) == 0x00 || (req->wIndex & 0xFF) == 0x01) { CDC_Setup(pdev, req); } else if ((req->wIndex & 0xFF) == 0x02) { HID_Setup(pdev, req); } else { // 未知接口号,返回非法请求 return USBD_FAIL; } return USBD_OK; }req->wIndex是个复合值：请求里的 wIndex 字段同时包含接口号和端点号信息，通过& 0xFF取出低 8 位就是接口号。这样按接口号分发请求是组合设备里最稳妥的判段方式。
5. 组合设备避坑指南:枚举失败、描述符错位、数据卡死的 5 个排查点
5.1 枚举失败:设备管理器中显示“未知 USB 设备”
现象：插上设备后，Windows 设备管理器里出现“未知 USB 设备”，没有报错详情，也没有功能节点。
原因：这种问题 90% 出在配置描述符的结构上。最常见的是wTotalLength字段与实际数组长度不一致，或者接口总数bNumInterfaces填了 2（只算了 HID 和 CDC 通信接口，漏掉 CDC 数据接口）。
解决：用 USB 分析仪或者逻辑分析仪抓取枚举阶段的 GET_DESCRIPTOR 请求，比对主机请求的数据长度和固件返回的数据长度。最简单的方式是逐个字节核对CFG_TOTAL_LEN。核对技巧：把描述符数组里的所有描述符长度加起来，再加 9 字节的配置描述符头，必须等于这个宏的值。我在代码里写过断言：
// 编译期检查描述符总长度是否正确 // 如果 CFG_TOTAL_LEN 与实际不符,编译报错 STATIC_ASSERT(sizeof(USBD_ConfigDescriptor) == CFG_TOTAL_LEN);5.2 配置描述符裁剪:Host 请求长描述符时返回不完整
现象：设备枚举成功，但 HID 或 CDC 中的一个功能丢失，另一个功能正常。
原因：主机枚举时先读配置描述符的 9 字节头部获取wTotalLength，然后再按这个长度读完整描述符。有些精简版的协议栈实现里，配置描述符的处理函数用了一个固定大小的数组来承载，如果你的组合描述符超过这个数组长度，后面的接口描述符会被截断。
解决：检查USBD_CFG_MAX_NUM（协议栈支持的最大配置数）和描述符缓冲区的长度设置。我实际遇到过一次，代码里把缓冲区定义为uint8_t desc[64]，组合描述符实际长度 98 字节，后半段的 HID 接口全部被丢弃。把缓冲区长度改到 128 字节后恢复正常。
5.3 CDC 发送方向错误:数据到了但字节顺序反了
现象：虚拟串口能打开，但收发数据完全乱码，或者只能收不能发。
原因：这个坑不是描述符结构问题，而是端点方向配置错误。USB 端点的方向由端点地址的最高位决定：0x81 表示端点 1 IN（设备到主机），0x01 表示端点 1 OUT（主机到设备）。很多人把 IN 和 OUT 的方向理解反——从主机的视角看，IN 是从设备读数据，OUT 是往设备写数据。
解决：核对端点描述符的 bEndpointAddress 字段。CDC 数据接口的 IN 端点是 0x81，OUT 端点是 0x01；HID 的中断端点建议 0x84。如果方向反了，把描述符里的地址改过来，同时把代码里所有 CPC_Transmit 和 CDC_Receive 使用的端点宏同步修改。
5.4 HID 描述符长度字段与实际报告长度不一致
现象：设备枚举正常，但 HID 功能在 Linux 下无法使用，或 Windows 下 HID 设备只有电源管理选项。
原因：HID 描述符的wReportDescriptorLength字段填的是报告描述符的长度，这个值是主机读取后续数据的依据。如果实际报告描述符是 42 字节，但字段里填写了 64，主机读数据时会把后面不属于报告描述符的内容也读进去，解析失败后整个 HID 接口被标记为不可用。
解决：用一个宏统一管理报告描述符的长度。代码里的写法是：
#define HID_REPORT_DESC_SIZE 42 // HID 描述符里引用这个宏 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, LOBYTE(HID_REPORT_DESC_SIZE), HIBYTE(HID_REPORT_DESC_SIZE),然后在发送报告描述符的回调函数里也用同一个宏：
static uint8_t* HID_GetReportDesc(USBD_HandleTypeDef *pdev, uint16_t *length) { *length = HID_REPORT_DESC_SIZE; return HID_ReportDesc; }5.5 设备卡死在 USB 中断里:回调函数内做了耗时操作
现象：设备工作一段时间后完全无响应，USB 设备从设备管理器中消失，重新插拔恢复。
原因：USB 中断服务函数里做了耗时操作，比如在 CDC 的 RX 回调里直接处理数据、写 Flash、或者调用系统延时函数。USB 中断函数运行时间过长会导致主机侧认为设备超时，从而复位设备。主机复位后，设备端如果没有做好重新初始化端点缓冲区的准备，就会出现整个 USB 模块锁死。
解决：把所有实际的数据处理逻辑放到主循环中。中断回调只做一件事：把数据拷贝到环形缓冲区，置一个标志位。主循环检测到标志位后再做解析和转发。我处理过一例：在 CDC 回调里调用 HAL_Delay(10) 等另一个外设响应，结果 USB 枚举后约 30 秒必然掉线，把延时循环全部移除后问题消失。
6. 组合设备验证与进阶:用 USB 分析仪和参数化配置把功能做扎实
组合设备配置完之后，验证工作不能只看设备管理器里有没有“键盘”和“串口”两个节点，还要验证两个功能在并发工作时的表现。我通常的做法是：设备端循环发送 HID 按键报告，间隔 10ms；同时用另一路程序往上位机发送递增的计数数据。上位机同时开两个程序——一个用键盘钩子捕获按键事件，一个用串口助手接收计数数据并检查是否连续。
这里有三种验证情况需要关注：
- 只有 HID 正常，CDC 数据全丢——大概率是 USB 中断里处理不过来，检查是否有死循环或者过长处理
- 两者都正常，但 CDC 数据出现断流——HID 报告发送频率过高，USB 中断被 HID 独占
- 两者正常且长时间稳定运行——合格，可以收工
参数化配置是值得做的一步。把接口号、端点号、报告长度这些硬编码值集中到一个头文件里，后续换芯片型号时只改宏定义：
// composite_config.h #define COMPOSITE_CDC_INTF0 0 #define COMPOSITE_CDC_INTF1 1 #define COMPOSITE_HID_INTF 2 #define COMPOSITE_CDC_EP (0x81|0x80) // 数据 IN 端点 #define COMPOSITE_HID_EP 0x84 // HID 中断 IN 端点如果后续要把这个组合设备升级成三合一设备（加一个 MSC 大容量存储类），在此框架上修改时，重点看描述符的总长度和端点分配即可。MSC 和 HID 的 USB 类规范有硬件上的兼容性限制：MSC 需要批量传输端点，而 HID 的中断端点需要固定间隔，两者对 USB 带宽的占用模式差异很大，但端点资源足够的情况下可以共存。
在验证组合设备时，USB 分析仪几乎是必备工具。价格较低的方案是用 STM32 的另一个 USB 口配合软件做包抓取。注意抓包时的时序问题：抓包工具需要挂在设备和主机之间，不要直接并联，否则会对总线造成额外负载。
从那次之后，我每次改完组合设备都会强制走一遍完整验证：先抓枚举包看描述符结构，再同时跑 HID 和 CDC 的并发压力测试，最后调整报告发送频率测试极限。这套流程走到位，基本能在上机前就把最容易出的那几个问题全部拦下来。希望帮到你。
本文还有配套的精品资源，点击获取
