USB Control Transfer 与 Setup Packet 调试：读懂 bmRequestType、bRequest、wValue、wIndex

USB 控制传输是主机和设备之间第一场正经对话。枚举靠它，类初始化靠它，厂商自定义的初始化也常常靠它。控制传输一旦失败，用户那边可能只看到"设备没识别"或者"驱动失败"，但证据通常就在 Setup Packet 里。

对固件工程师来说，学会读 bmRequestType、bRequest、wValue、wIndex、wLength，是从拍脑袋到精确定位最快的一条路。

Setup Packet 就是请求契约

一个 USB Setup Packet 告诉设备：

• 传输方向
• 请求类型：Standard、Class、Vendor 还是 Reserved
• Recipient：Device、Interface、Endpoint 还是 Other
• Request Code
• Value 字段
• Index 字段
• 期望的数据长度

如果固件把这些字段解错了，就可能回错描述符、STALL 掉一个合法的请求、或者接受一条不该接受的命令。如果主机发了一个意料之外的请求，抓包也能直接看到。

GET_DESCRIPTOR 是第一个落脚点

枚举期间，主机会发标准描述符请求。常见的模式包括：

• Device Descriptor 请求
• Configuration Descriptor 请求
• String Descriptor 请求
• HID 设备的 HID Report Descriptor 请求
• 较新主机的 BOS Descriptor 请求

在 Setup Packet 里，bRequest 标识 GET_DESCRIPTOR，wValue 包含描述符类型和描述符 index。wIndex 在字符串描述符里可能是语言 ID，在类特定描述符里可能是接口号。wLength 告诉设备主机期望多少字节。

描述符响应长度错了，或者固件返回的字节不够主机要，枚举就会在后面看起来毫无关联的地方失败。

方向错了代价很大

控制传输是有方向的。Device-to-Host 的请求要回数据，Host-to-Device 的请求要么带数据要么配置状态。如果固件把读请求当写处理，或者在写请求里回数据，主机可不会替你猜意图。

重点排查：

• IN 方向但没有数据阶段
• OUT 方向但固件在等发数据
• 缺了零长度的状态阶段
• 对合法的标准请求返回 STALL
• 类请求被路由到了错误的接口

抓包应该完整呈现请求、数据阶段、状态阶段。

类请求和厂商请求要看接口上下文

枚举完成之后，类驱动会发类特定请求。CDC 可能发 Line Coding 请求，HID 可能请求 Report Descriptor 或 Feature Report，厂商工具可能发初始化命令。同一个 bRequest 取值，在不同的请求类型和 Recipient 下可能含义完全不同。

要看的：

• 请求类型
• Recipient
• wIndex 里的接口号
• Recipient 为 Endpoint 时的端点号
• Payload 字节
• 响应或 STALL

组合设备有多个接口的时候，请求路由错接口是一类高频 bug。

Bus Scope 在这个场景里做什么

Bus Scope 是为 USB 证据而生的工具。控制传输调试需要"解析后的 setup 字段"和"原始字节"挨在一起。最好的视图是：固件工程师一边读语义字段，一边还能校验真实的包字节。

一份合格的 Bus Scope 控制传输调试会话，应该回答：

• 哪一条 Setup Packet 失败了？
• 是 Standard、Class 还是 Vendor？
• 请求的是哪个描述符或接口？
• 设备有没有返回期望的长度？
• 固件的 STALL 是主动的，还是误判？
• 后面哪一步枚举依赖于这次的响应？

工单上可能只写着"USB 控制传输失败"，但修复点通常藏在那个 5 字段的 Setup Packet 里。