Windows侧USB设备枚举过程综述

1. 术语

2. USB协议基本知识

关于USB协议相关知识点，本章节只是讲解USB枚举过程中，需要用到的一些知识点，比如USB协议中定义的几种USB设备状态、USB控制器与USB设备之间的控制包交互，也就是setup数据包，以及USB设备需要上报的一些描述符信息，至于其他相关信息，请自行查看USB协议文档。

2.1 USB设备状态

USB协议规定了USB设备拥有几种设备状态，各个设备状态之间的转换关系，如下图所示，下面重点讲解如下几种状态。

• Attached：USB设备可以连接到总线或者从总线上移除.USB设备从总线上拨出后的状态在规范没定义,只说明一旦USB设备连到总线要求的操作以及属性。
• Powered：主机侧检测到USB设备后，会给USB设备供电。USB设备的电源可来自外部电源，也可从USB接口的集线器而来。
• Default：设备上电后,它不响应任何总线处理,直到总线接收到复位信号为止.接收到复位信号后,用默认的地址可以对设备寻址
• Address：所有的USB设备在加电复位以后都使用缺省地址。每一设备在连接或复位后由主机分配一个唯一的地址
• Configured：在USB设备正常工作以前，设备必须被正确配置。从设备的角度来看，配置包括一个将非零值写入设备配置寄存器的操作。配置一个设备或改变一个可变的设备设置会使得与这个相关接口的终端结点的所有的状态与配置值被设成缺省值
• Suspended：为节省电源，USB设备在探测不到总线传输时自动进入中止状态。当中止时，USB设备保持本身的内部状态，包括它的地址及配置

上述只简单讲解了各个状态的一些关键点，如需更详细的信息，请自行查阅USB 3.2协议中的9.1.1.1-9.1.1.7小节。

2.2 Setup数据包

USB控制器与USB设备之间存在四种传输模式，分别为Data Flow，Control Transfer，Interrupt Transfer和Isochronous Transfer，其中Control Transfer这种传输模式非常重要，因为其可以保证数据的正确性，在设备的枚举过程中都是使用控制传输的。控制传输分为三个阶段：setup阶段、data阶段和ack阶段，下面简单讲解这三个阶段，具体详细细节，请自行查阅USB 3.2协议中的8.12.2小节。

• setup阶段：由主机侧主动发起，它是一个setup数据包，里面包含一些数据请求的命令以及一些请求参数。
• data阶段：该阶段用来主机与USB设备之间进行数据传输。如果setup阶段是输入请求，那么data阶段就要输入数据；如果setup阶段是输出请求，那么data阶段就要输出数据。
• ack阶段：该阶段用来确认数据的正确传输,而ack阶段刚好跟data阶段相反，如果是输入请求，则它是一个输出数据包；如果是输出请求，则它是一个输入数据包。

下面重点讲解setup数据包，其大小8个字节，具体格式如下所示。

2.2.1 bmRequestType

bmRequestType域大小为1个字节，解决了向谁请求的问题，其格式如下所示。

• D7：传输方向
  0=主机至设备；1=设备至主机
• D6…5：命令类型
  D6D5=00：标准请求命令； D6D5=01：类请求命令；
  D6D5=10：用户定义命令； D6D5=11：保留。
• D4…0：接受者类型
  0=设备；1=接口 ；
  2=端点；3=其它
  4…31 保留
• D7 bit表明了第二阶段控制传输方向，如果wLength域被设作0的话，表明没有数据传送阶段，那Direction位就会被忽略。
• D6…5 bit表明了请求的命令类型，因为USB协议定义了一系列标准的请求，而这些请求针对所有的USB设备，同时不同类型的USB设备也定义该设备类特定的请求，俗称类定义请求，最后USB厂商也可以自定义请求命令。
• D4…0 bit表明了该请求的接收者，其中包括了设备，接口和EP上，当指定的接收者为接口或EP时，wIndex域指定了那个接口或EP节点。

2.2.2 bmRequest

bmRequest大小为1个字节，解决了请求什么的问题，也就是请求命令码，其中包括了标准请求命令码、类定义请求命令码以及USB设备厂商自定义的命令码。本文只给出标准请求命令码，请参考附录7.1小节，而类定义请求命令码，请查看相关设备类的相关协议文档，而附录7.2小节会给出CDC设备类的请求命令码。

2.2.3 wValue域

此域用来传送当前请求的参数，随请求不同而不同。

2.2.4 wIndex域

当bmRequestType的Recipient字段为接口或端点时，wIndex域用来表明是哪一个接口或端结。

2.2.5 wLength域

这个域表明第二阶段的数据传输长度。传输方向由bmRequstType域的Direction位指出。wLength域为0则表明无数据传输。在输入请求下，设备返回的数据长度不应多于wLength，但可以少于。在输出请求下，wLength指出主机发出的确切数据量。如果主机发送多于wLength的数据，设备做出的响应是无定义的。

2.3 USB设备相关描述符

在USB中USB HOST是通过各种描述符来识别设备的，有设备描述符，配置描述符，接口描述符，端点描述符，字符串描述符等，这些描述符之间的关系如下图所示。

2.3.1 设备描述符

设备描述符代表一个USB设备，它由一个或多个配置组成。设备描述符用于说明设备的总体信息，并指出其所包含配置的个数。下面给出设备描述符的结构体，如下所示。

//
// USB 1.1: 9.6.1 Device, Table 9-7. Standard Device Descriptor
// USB 2.0: 9.6.1 Device, Table 9-8. Standard Device Descriptor
// USB 3.0: 9.6.1 Device, Table 9-8. Standard Device Descriptor
//
typedef struct _USB_DEVICE_DESCRIPTOR {
    UCHAR   bLength;
    UCHAR   bDescriptorType;
    USHORT  bcdUSB;
    UCHAR   bDeviceClass;
    UCHAR   bDeviceSubClass;
    UCHAR   bDeviceProtocol;
    UCHAR   bMaxPacketSize0;
    USHORT  idVendor;
    USHORT  idProduct;
    USHORT  bcdDevice;
    UCHAR   iManufacturer;
    UCHAR   iProduct;
    UCHAR   iSerialNumber;
    UCHAR   bNumConfigurations;
} USB_DEVICE_DESCRIPTOR, *PUSB_DEVICE_DESCRIPTOR;

关于设备描述符的详细含义，请查看USB 3.2协议中的9.6.1小节。

2.3.2 配置描述符

在使用USB设备前，必须为其选择一个合适的配置，如USB设备的低功耗模式和高功耗模式分别对应一个配置。配置描述符用于说明USB设备中各个配置的特性。下面给出配置描述符的结构体，如下所示。

//
// USB 1.1: 9.6.2 Configuration, Table 9-8. Standard Configuration Descriptor
// USB 2.0: 9.6.3 Configuration, Table 9-10. Standard Configuration Descriptor
// USB 3.0: 9.6.3 Configuration, Table 9-15. Standard Configuration Descriptor
//
typedef struct _USB_CONFIGURATION_DESCRIPTOR {
    UCHAR   bLength;
    UCHAR   bDescriptorType;
    USHORT  wTotalLength;
    UCHAR   bNumInterfaces;
    UCHAR   bConfigurationValue;
    UCHAR   iConfiguration;
    UCHAR   bmAttributes;
    UCHAR   MaxPower;
} USB_CONFIGURATION_DESCRIPTOR, *PUSB_CONFIGURATION_DESCRIPTOR;

关于配置描述符的详细含义，请查看USB 3.2协议中的9.6.3小节。

2.3.3 接口描述符

一个配置可以包含一个或多个接口。接口是一个端点的集合。接口描述符用于说明USB设备中各个接口的特性。下面给出接口描述符的结构体，如下所示。

//
// USB 1.1: 9.6.3 Interface, Table 9-9. Standard Interface Descriptor
// USB 2.0: 9.6.5 Interface, Table 9-12. Standard Interface Descriptor
// USB 3.0: 9.6.5 Interface, Table 9-17. Standard Interface Descriptor
//
typedef struct _USB_INTERFACE_DESCRIPTOR {
    UCHAR   bLength;
    UCHAR   bDescriptorType;
    UCHAR   bInterfaceNumber;
    UCHAR   bAlternateSetting;
    UCHAR   bNumEndpoints;
    UCHAR   bInterfaceClass;
    UCHAR   bInterfaceSubClass;
    UCHAR   bInterfaceProtocol;
    UCHAR   iInterface;
} USB_INTERFACE_DESCRIPTOR, *PUSB_INTERFACE_DESCRIPTOR;

关于接口描述符的详细含义，请查看USB 3.2协议中的9.6.5小节。

2.3.4 端点描述符

端点是USB设备中的实际物理单元，USB数据传输就是在主机和USB设备各个端点之间进行的。下面给出端点描述符的结构体，如下所示。

//
// USB 1.1: 9.6.4 Endpoint, Table 9-10. Standard Endpoint Descriptor
// USB 2.0: 9.6.6 Endpoint, Table 9-13. Standard Endpoint Descriptor
// USB 3.0: 9.6.6 Endpoint, Table 9-18. Standard Endpoint Descriptor
//
typedef struct _USB_ENDPOINT_DESCRIPTOR {
    UCHAR   bLength;
    UCHAR   bDescriptorType;
    UCHAR   bEndpointAddress;
    UCHAR   bmAttributes;
    USHORT  wMaxPacketSize;
    UCHAR   bInterval;
} USB_ENDPOINT_DESCRIPTOR, *PUSB_ENDPOINT_DESCRIPTOR;

关于端点描述符的详细含义，请查看USB 3.2协议中的9.6.6小节。

2.3.5 字符串描述符

字符串描述符是可选的，就像前面所示的那样，如果一个USB设备不支持设备描述符、配置描述符和接口描述符所引用的字符串，那么这些描述符中所有引用的字符串索引值必须设置为0。下面给出字符串描述符的结构体，如下所示。

//
// USB 1.1: 9.6.5 String, Table 9-12. UNICODE String Descriptor
// USB 2.0: 9.6.7 String, Table 9-16. UNICODE String Descriptor
// USB 3.0: 9.6.8 String, Table 9-22. UNICODE String Descriptor
//
typedef struct _USB_STRING_DESCRIPTOR {
    UCHAR   bLength;
    UCHAR   bDescriptorType;
    WCHAR   bString[1];
} USB_STRING_DESCRIPTOR, *PUSB_STRING_DESCRIPTOR;

关于字符串描述符的详细含义，请查看USB 3.2协议中的9.6.9小节。

3. USB设备枚举过程

Windows侧主机检测到USB设备插入后，就要对设备进行枚举了。枚举的作用就是从设备那里读取一些信息，知道是什么样的设备，这样主机就可以根据这些信息加载合适的驱动程序。下面给出Windows侧复合设备通用的枚举过程，如下所示。

1. 用户将USB设备插入到集线器端口，也就是HUB端口

2. HUB端口通过检测D+,D-数据线的电压情况，判断有新设备插入，具体步骤，请查看附录7.3小节。

3. 当检测到设备后，hub继续给设备供电，但并不急于与设备进行USB传输。

4. 当完成1-3之后，USB设备的状态从初始attached-》powered。

5. 每一个hub都有自己的中断端点向主机上报它的端口状态（对于这个过程，设备是不可见的，也就是USB分析仪抓取不到该过程，这个是主机侧自身的行为），报告的内容只是HUB端口的设备连接/端口的事件。

6. hub端口上报系统有新设备连接后，系统下发Get_Port_Status请求到hub了解新设备的基本信息（比如设备的速度类型等信息，插入或者移除设备事件等）

7. 系统知道有新设备到达，并知道一些基本信息后，至少等待100ms后，主机控制器向hub发出一股Set_Port_Feature请求，让hub执行端口复位操作（hub通过驱动数据线d+,d-到低电平状态，并持续至少10ms）

8. 如果host获取到设备是全速设备的话，那么系统会进行高速检测，查看该设备是否支持高速传输，如果是，切换到高速信号模式，具体过程，请查看USB总线协议。

9. 系统不停向hub发送Get_Port_Status请求，以查询设备是否复位成功。hub返回的信息中，有一位用来标志设备的复位状态。

10. 当复位成功后，设备处于default状态（地址为0），此时主机与设备可以通过address=0，ep=0，进行控制信息的交互，也就是通过setup数据包完成信息的交互。

11. 此时Hub驱动，也就是usbhub3.sys，会下发标准请求命令码GET_DESCRIPTOR（bmRequest=0x6，wValue=0x0100，其中Descriptor Type =0x01，Descriptor Index=0x00）来第一次获取USB设备描述符信息，具体如下图所示，主要获取默认管道EP0的最大包长度bMaxPacketSize0和设备描述符的长度信息，其他信息瞄一眼即可，驱动暂不关心。
    

12. 当完成上述请求后，系统会要求hub，对设备再次复位（USB规范没有该要求）。再次复位的目的使设备进入到一个确定的状态。

13. Hub驱动通过SET_ADDRESS（bmRequest=0x5，wValue=addr）标准请求向USB设备分配唯一地址，后面的所有通信都通过该地址进行，此时设备处于address状态，比如如下所示，给USB设备分配的地址为0x24
    

14. 完成USB设备地址分配后，Hub驱动就会通过该地址，第二次获取该设备的设备描述符信息，就像步骤11中所示的那样，而这一次，诚意满满，Hub驱动会认真解析设备描述符的所有信息，当然Hub驱动也会获取一些其他有用的描述符信息，比如配置描述符以及iProduct字符串等信息，这里就不再详细讲解了。
    

15. 当Hub驱动完全解析了USB设备描述符后，生成一个PDO节点，其硬件ID等于USB\VID_xxxx&PID_yyyy，其中xxxx为idVendor，而yyyy为idProduct，同时产生一个PNP事件，通知系统有新的PDO产生。

16. 同时也会判断该设备是否为composite device，关于判定为composite device的方法，请查看附录7.4小节。如果USB设备为复合设备的话，Hub驱动会给新生成的PDO，赋予一个兼容ID，其值为USB\COMPOSITE。

17. 在检索到新PDO的硬件和兼容ID后，操作系统会搜索相应的INF文件，搜索原则如下：
    (1）优先查找跟硬件ID匹配的INF文件，如果找到，则安装该INF文件指定的驱动。
    (2）否则没有硬件ID匹配的INF文件，由于该PDO有一个兼容ID，那边系统就会查找跟兼容ID匹配的INF文件，如果找到的话，则安装INF文件指定的驱动。
    (3）由于该PDO兼容ID为USB\COMPOSITE，结果查找到了USB.inf文件，进而触发系统安装usbccgp.sys驱动。
    注意：
    （1），（2）步骤适用于Windows侧所有的PDO驱动安装。

18. 当usbccgp.sys驱动执行时，会先下发标准请求GET_DESCRIPTOR获取设备描述符信息，之后通过两次下发GET_DESCRIPTOR（bmRequest=0x6，wValue=0x0200，其中Descriptor Type =0x02，Descriptor Index=0x00）获取完整的配置描述符信息。
    

19. usbccgp.sys驱动通过SET_CONFIGURATION（bmRequest=0x9，wValue=cfgvalue）下发配置配置值到USB设备，此时USB设备进入到Configured状态，下面给出一个例子，主机侧驱动下发的配置值为0x1，如下所示。

20. usbccgp.sys驱动解析配置描述符后，会依次将配置描述符中的每一个interface group都生成一个PDO子设备节点，而子节点的硬件ID为USB\VID_v(4)&PID_p(4)&MI_z(2)，而子节点的兼容ID为USB\CLASS_d(2)&SUBCLASS_s(2)&PROT_p(2)，关于硬件ID和兼容ID中的各个字段含义，请查看附录7.5小节。关于这如何将配置描述符中的interface组织成group，这一部分有点复杂，本文档就不再讲解，而会在另外一个文档中详细介绍。
21. 系统会依次给usbccgp.sys驱动生成的PDO子节点，加载相应的驱动，加载过程跟步骤17中的一样，都是先找硬件ID配备的INF，然后再找兼容ID配备的INF，下面以FIBO L830模块为例讲解，L830模块导出两个interface group，其中第一个加载了微软的内置驱动cxwmbclass.sys，如下所示，因为我们没有给该接口提供跟硬件ID配备的驱动，所以系统自动加载兼容ID（USB\Class_02&SubClass_0e&Prot_00）匹配的微软内置驱动。

22. 当各个子节点加载驱动后，剩下的行为，就是由各个子节点的驱动来决定了，比如有的interface驱动会执行查询iManufacturer字符串，下发SET_INTERFACE标准请求等，这里就不在给出某个子节点驱动的具体行为了，章节6会给出MBIM接口驱动cxwmbclass.sys的具体行为。

4. L830模块实例讲解

L830模块是基于Intel芯片，而且该模块经过大批量发货，已经验证了稳定性和可靠性，具有典型代表，所以基于该模块进行实例讲解，如下所示。关于windows系统侧的行为，这里就不在讲解了，直接从模块被复位到默认状态开始，也就是模块的addr=0,ep=0，而且主机与模块开始控制信息的交互，下面以PC机root hub3.0为例讲解。

1. usbhub3.sys驱动下发GET_DESCRIPTOR第一次获取L830模块的设备描述符信息，具体如下图所示。
   

2. 主机侧再次复位模块完成后，usbhub3.sys驱动通过SET_ADDRESS给L830模块分配地址为25
   

3. usbhub3.sys驱动下发GET_DESCRIPTOR第二次获取L830模块的设备描述符信息，如下所示
   

4. usbhub3.sys驱动下发GET_DESCRIPTOR获取L830模块的配置描述符，iSerialNumber、iProduct以及语言ID描述符信息，如下所示。
   

5. 当加载usbccgp.sys驱动后，该驱动会再次获取L830模块的设备描述符以及配置描述符信息，如下所示。

6. usbccgp.sys驱动通过SET_CONFIGURATION给L830模块下发配置参数0x1，让模块处于Configured状态，如下所示。
   

7. 当usbccgp.sys驱动解析完L830模块的配置描述符后，会生成两个子节点，一个MBIM节点，一个串口节点，如下所示，同时这两个节点都会分别自动加载微软的内置驱动：cxwmbclass.sys和usbser.sys。
   

8. 当cxwmbclass.sys驱动加载后，会下发两次SET_INTERFACE标准请求命令码（bmRequest=0x0B）分别将interface 0，interface 1的Alternate值先复位为0。
   

9. 模块会上报两次芯片自定义的标准请求（请求码为0xFE），如下所示。

10. cxwmbclass.sys和usbser.sys驱动启动过程中都会获取一些字符串相关信息，比如运营商字符串、产品字符串以及MBIM接口索引字符串信息等，下面只给出一部分信息，如下所示。
    
11. L830模块上报标准请求GET_STATUS，如下所示，详细的状态信息，请查看USB 3.2协议文档9.4.5小节。
    
12. cxwmbclass.sys下发SET_INTERFACE标准请求命令码（bmRequest=0x0B）分别将interface 0的Alternate值设置为1，如下所示。

13. L830模块主动上报NCM类标准请求码0x80（get_ntb_parameters），如下所示
    

14. cxwmbclass.sys驱动发送MBIM类标准请求码0x05(RESET_FUNCTION) 到模块侧，如下所示
    

15. cxwmbclass.sys驱动下发NCM类标准请求码0x86(set_ntb_input_size)到模块侧，如下所示
    

16. cxwmbclass.sys驱动重复步骤14和15的操作，分别再次下发0x05RESET_FUNCTION和0x86(set_ntb_input_size)，如下所示，至于为什么再次发送这两个请求码，待研究。
    

17. cxwmbclass.sys下发SET_INTERFACE标准请求命令码（bmRequest=0x0B）分别将interface 1的Alternate值设置为2，如下所示。
    

18. 主机侧这边开始下发标准MBIM命令，首先下发OPEN命令，模块侧返回OPEN_DONE，如下图所示。
    

19. 剩下的就是标准MBIM命令的交互了，这里就不再详细一一讲解了，只简单给出一个标准的MBIM命令，也就是MBIM_COMMAND和MBIM_COMMAND_DONE，如下图所示。
    

5. 附录

5.1 标准请求命令码

本小节给出了适用所有USB设备的标准设备请求，表9-4概括出了这些标准请求，而表9-5给出了标准请求命令码，表9-6给出了描述符类型信息。




关于各个标准请求命令码的详情，请查看USB 3.2协议中的9.4.1-9.4.13小节。

5.2 CDC设备类请求命令码

5.3 检测到USB设备步骤

在hub端，数据线D+和D-都有一个阻值在14.25k到24.8k的下拉电阻Rpd，而在设备端，D+（全速，高速）和D-（低速）上有一个1.5k的上拉电阻Rpu。当设备插入到hub端口时，有上拉电阻的一根数据线被拉高到幅值的90%的电压（大致是3V）。hub检测到它的一根数据线是高电平，就认为是有设备插入，并能根据是D+还是D-被拉高来判断到底是什么设备（全速/低速）插入端口（全速、高速设备的区分在我将来的文章中描述），如下图所示。

5.4 Composite设备判断方法

只要满足如下两个条件的一个，windows系统就认为USB设备为composite设备。

5.4.1 条件1

满足如下要求：

1. USB设备描述符中的bDeviceClass=0xEF，bDeviceSubClass=0x02，bDeviceProtocol=0x01
2. USB设备必须只有单个配置，也就是设备描述符中的bNumConfigurations=0x1
3. 配置描述符中必须包含多个interface

5.4.2 条件2

满足如下要求：

1. USB设备描述符中的bDeviceClass=0x0，bDeviceSubClass=0x0，bDeviceProtocol=0x0即可。

5.5 Interface PDO硬件ID和兼容ID

子节点硬件ID为USB\VID_v(4)&PID_p(4)&MI_z(2)，各个字段含义如下所示：

1. v(4)代表vendor code，也就是设备描述符中的idVendor
2. p(4)代表product code，也就是设备描述符中的idProduct
3. z(2) 代表interface number，也就是interface描述符中的bInterfaceNumber
   子节点兼容ID为USB\CLASS_d(2)&SUBCLASS_s(2)&PROT_p(2)，各个字段含义如下所示：
4. d(2)代表接口class，也就是interface描述符中的bInterfaceClass，
5. s(2) 代表接口子类，也就是interface描述符中的bInterfaceSubClass，
6. p(2) 代表接口协议类型，也就是interface描述符中的bInterfaceProtocol。