USB枚举流程详解：从设备连接到配置选择
枚举，说白了就是USB主机和设备之间的一场「自我介绍」和「身份确认」。设备插上去，主机怎么知道你是谁？需要什么驱动？怎么跟你通信？这一整套流程，就是枚举。
我刚开始做USB驱动时，总觉得枚举很简单——不就是发几个请求嘛。直到有一次，设备在复位阶段就卡死了，我拿着逻辑分析仪蹲了一整天，才发现是D+上拉电阻的时序不对。嗯，从那以后，我对枚举的每一个字节都不敢马虎。
2.1 枚举的六个核心阶段
一次完整的USB枚举，可以拆成六个步骤。每一步都有明确的目标，缺一不可。
| 阶段 | 动作 | 关键信号/事务 | 常见失败点 |
|---|---|---|---|
| 1. 设备连接 | 设备插入，D+/D-电平变化 | 上拉电阻生效，主机检测到状态变化 | 上拉电阻未使能、电平不匹配 |
| 2. 总线复位 | 主机拉低D+/D-至少10ms | SE0状态，设备复位到默认地址0 | 复位时间不足、设备未响应 |
| 3. 地址分配 | 主机发送SET_ADDRESS请求 | 控制传输，设备获得唯一地址 | 地址冲突、设备未确认 |
| 4. 描述符请求 | 主机获取设备/配置/接口/端点描述符 | GET_DESCRIPTOR请求 | 描述符长度错误、数据格式异常 |
| 5. 配置选择 | 主机发送SET_CONFIGURATION | 设备进入配置状态，功能可用 | 配置值无效、电源需求超限 |
| 6. 驱动加载 | 主机根据描述符匹配驱动 | 操作系统加载对应驱动 | VID/PID未识别、驱动签名问题 |
核心要点：枚举的每一步都是「请求-响应」的握手。主机发一个令牌，设备必须在规定时间内回复。超时或回复错误，枚举就会中断。
2.2 设备连接与复位
设备插入USB口的那一刻，物理层就开始工作了。全速和低速设备通过D+或D-上的上拉电阻来告诉主机自己的速度。高速设备则更复杂一些——它先以全速身份连接，再通过Chirp握手切换到高速模式。
我记得有一次调试一个高速设备，插上去主机死活不认。量了D+电平，发现上拉电阻已经拉起来了，但主机就是不给复位信号。后来查了协议才知道——高速设备必须在复位期间完成Chirp J/K序列，否则主机认为它只是个全速设备。那根线的时序差了那么几微秒，整个枚举就废了。
复位阶段的时序要求
- 复位持续时间：至少10ms，主机驱动D+/D-到SE0状态
- 设备行为：复位结束后，设备回到默认地址0，端点0可用
- 高速握手：设备在复位期间检测到主机Chirp K，则回复Chirp J/K序列
避坑指南：我曾经遇到一个设备，复位后端点0的MaxPacketSize设置错了。全速设备应该是64字节，我设成了8字节。主机第一次GET_DESCRIPTOR只读前8个字节，结果描述符被截断，枚举直接失败。后来我养成了一个习惯——复位后第一件事，确认端点0的MaxPacketSize与设备速度匹配。
2.3 地址分配
复位之后，设备还在默认地址0上。但总线上可能挂多个设备，地址0是共享的。所以主机做的第一件事，就是给新设备分配一个唯一地址。
这个过程通过一个控制传输完成：主机发送SET_ADDRESS请求，设备收到后返回0长度的状态包，然后切换到新地址。注意——设备必须在状态阶段完成后才能使用新地址，这个时序不能搞反。
// SET_ADDRESS 请求格式
// bmRequestType: 0x00 (主机到设备，标准请求，设备接收)
// bRequest: 0x05 (SET_ADDRESS)
// wValue: 新地址 (1-127)
// wIndex: 0x0000
// wLength: 0x0000
// 主机发送的Setup包示例
0x00 0x05 0x01 0x00 0x00 0x00 0x00 0x00
// 地址为1，无数据阶段个人经验：地址分配阶段最容易出的问题，是设备在状态阶段之前就切换了地址。主机还在等设备用地址0回复，设备却已经跳到新地址了——两边对不上，枚举卡死。我建议在固件里严格按协议走：收到SET_ADDRESS后，先完成状态阶段，再更新地址寄存器。
2.4 描述符请求
地址分配完成后，主机开始疯狂要描述符。这是枚举中最复杂、也最容易出问题的阶段。主机通过GET_DESCRIPTOR请求，一步步获取设备的信息。
描述符请求的顺序
- 设备描述符：主机先读前8字节（获取MaxPacketSize），再读完整18字节
- 配置描述符：主机读前4字节（获取总长度），再读完整配置描述符+所有接口和端点描述符
- 字符串描述符：如果设备描述符中有字符串索引，主机可能请求语言ID和具体字符串
| 描述符类型 | 长度 | 关键字段 | 常见错误 |
|---|---|---|---|
| 设备描述符 | 18字节 | USB版本、VID/PID、MaxPacketSize0 | bMaxPacketSize0与实际端点不匹配 |
| 配置描述符 | 9字节 + 接口/端点描述符 | 总长度、接口数量、供电方式 | wTotalLength与实际数据不符 |
| 接口描述符 | 9字节 | 接口号、端点数量、类/子类/协议 | bInterfaceNumber重复或跳号 |
| 端点描述符 | 7字节 | 端点地址、传输类型、最大包大小 | bEndpointAddress与硬件不匹配 |
关键提醒：描述符里的长度字段必须与实际返回的数据一致。我见过一个案例，配置描述符的wTotalLength写的是32，但实际返回了40字节。主机读到32就停了，后面的接口描述符全丢了。这种错误，逻辑分析仪一抓一个准。
2.5 配置选择
主机拿到所有描述符后，已经知道设备的能力了。接下来它要选择一个配置，让设备进入工作状态。这一步通过SET_CONFIGURATION请求完成。
设备收到这个请求后，需要根据配置值初始化对应的端点、分配缓冲区、启动功能逻辑。如果配置值无效，设备应该返回STALL。
// SET_CONFIGURATION 请求格式
// bmRequestType: 0x00
// bRequest: 0x09 (SET_CONFIGURATION)
// wValue: 配置值 (通常为1)
// wIndex: 0x0000
// wLength: 0x0000
// 主机发送的Setup包示例
0x00 0x09 0x01 0x00 0x00 0x00 0x00 0x00
// 选择配置1避坑指南：我曾经做过一个复合设备，有两个配置：一个高功耗模式，一个低功耗模式。主机根据总线供电能力选择了低功耗配置，但我的固件在SET_CONFIGURATION时没有正确初始化所有端点。结果设备虽然枚举成功了，但数据传输时端点根本不响应。后来我加了一个配置切换的完整状态机，每个配置都独立初始化端点。
2.6 枚举流程全景图
下面这张图把整个枚举流程串起来了。你可以把它贴在工位上，调试时对着看，哪一步卡住了就查哪一步。
2.7 枚举失败的常见原因
枚举失败的原因千奇百怪，但归纳起来，无非是下面几类。我列了一个速查表，调试时可以直接对照。
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 设备插入后无反应 | 上拉电阻未使能、VBUS未供电 | 测量D+/D-电平，检查电源 |
| 复位后设备不响应 | 复位时间不足、端点0未初始化 | 用示波器看SE0持续时间 |
| SET_ADDRESS失败 | 设备提前切换地址、状态阶段未完成 | 抓控制传输，检查握手包 |
| 描述符请求超时 | 描述符长度错误、数据阶段未回复 | 对比描述符实际数据与声明长度 |
| SET_CONFIGURATION返回STALL | 配置值无效、端点资源不足 | 检查固件配置处理逻辑 |
| 驱动加载失败 | VID/PID未注册、驱动签名问题 | 查看设备管理器错误码 |
我的调试习惯：每次枚举失败，我第一件事不是看代码，而是抓USB总线数据。逻辑分析仪或USB分析仪能告诉你主机发了什么、设备回了什么。很多时候，问题在数据层面一眼就能看出来——描述符少了一个字节，或者地址回复错了。别靠猜，靠数据说话。
枚举是USB通信的基石。这一步走不通，后面所有功能都是空谈。把枚举流程吃透，你就能解决80%的USB设备问题。剩下的20%，无非是协议细节和硬件时序的变种——有了这个基础，排查起来也不会太费劲。