USB enumeration Process "Go"

transferred from: http://blog.csdn.net/myarrow/article/details/82700291. What is an enumeration? Enumeration is to read some information from the device, know what device it is, how to communicate, so that the host can be based on this information to load the appropriate driver.       To debug a USB device, it is important that the USB enumeration process, as long as the enumeration succeeds, then it is half the success. In the USB architecture, the hub is responsible for detecting the connection and disconnection of the device, using its interrupt in endpoint (Interrupt in Endpoint) to report to the host. at system startup, the host polls its root hub for the status of the device (including the child hub and the device on the child hub) to see if it is connected. See the USB bus topology (top of the host's root Hub): USB bus Topology

Once the new device is known to be connected, the host sends a series of requests (resqusts) to the hub that the device is attached to, and the hub establishes a communication channel between the host and the device. The host then sends various requests to the device via endpoint 0 (Endpoint 0) in a controlled transmission (control Transfer), and the device replies to the request after receiving the host, and then enumerates (enumerate) operations. All USB devices must support standard request (standardrequests), control transfer Mode (Transfer), and endpoint 0 (Endpoint 0).

Before explaining the enumeration, let's talk about a transmission mode of USB--control transmission. This transmission is very important in USB, it is necessary to ensure the correctness of the data, in the device enumeration process is used to control transmission. The control transmission is divided into three stages: ① establishment phase. ② data phase. ③ Confirmation phase.

Setup phase: is initiated by a USB host, which is a setup packet containing some data request commands and some data. If the setup phase is the input request, then the data stage is the input data, if the establishment phase is the output request, then the data phase will be output data. If in the data phase, even if you do not need to transfer data, also send a 0-length packet. After the data phase is the confirmation phase. The confirmation phase is just the opposite of the data stage, which is an output packet if it is an input request, or an input packet if it is an output request. The confirmation phase is used to confirm the correct transmission of the data.

1.1 Communication Transport Stream

1.2 Device status Diagram

1.3 Explanation of status

1) connection (attached)
The device can be connected to USB or unplugged from USB. The status of the USB device when it is dialed out of the bus is not defined in the specification, only the operation and properties that are required by the USB connection to the bus.

2) Power-on (Powered)
The USB device can be powered from an external power source or from a USB port hub. A USB device powered from an external power source is known as a self-contained power supply (self-powered). Although a self-contained USB device may have been charged before the USB interface is connected, they are not considered to be power-up (Powered state) until the USB interface is wired. At this time, Vbus has been a function of the equipment.
A device may have both a self-contained power supply and a bus power-supply configuration. Some support one of these, while others may be used only under self-contained power. The ability of the device to support power is reflected by the configuration description Table (config descriptor). The current power supply form is reflected as part of the state of the device. Devices can change their source of power at any time, such as: from the self-contained to the bus-style change, if a configuration supports both modes, then the maximum power requirement of this state is the device in both modes from the Vbus to obtain the maximum power. The device must use this maximum power supply as a reference, and it is not considered in what state. If one of the configurations supports only one power mode, a change in the power mode will cause the device to lose its current configuration and address and return to the powered-up state. If a device is self-contained and the current configuration requires more than 100mA current, then if the device goes to the bus power supply, it must return the address state. The self-contained power hub uses Vbus to provide power to the hub controller, so it can remain configured (configured state), although the self-contained power supply stops providing power.

3) Default state (defaults)

When the device is power-up, it does not respond to any bus processing until the bus receives the reset signal. After receiving the reset signal, the device can be addressed with the default address.
When the reset process is complete, the USB device operates at the correct speed (i.e. low speed/full speed/fast). Data selection at low and full speed is determined by the device's terminating resistor. A device capable of high-speed operation determines whether it performs high-speed operation in part of the reset process.
Equipment capable of high-speed operation must be able to be successfully reset at full speed when operating in a full speed electrical environment. After the device has been successfully reset, the device must successfully respond to the device and configuration descriptor requests, and return the appropriate information. When working at full speed, the device might or may not support pre-defined functionality.

4) Address
All USB devices use the default address after the power-on reset. Each device is assigned a unique address by the host after the connection or reset. When the USB device is in a suspended state, it keeps the address intact.
The USB device responds only to the default channel (Pipe) request, regardless of whether the device has been assigned an address or is using the default address.

5) configuration status (configured)
The device must be configured correctly before the USB device is working properly. From the device's point of view, the configuration includes an operation that writes a non-0 value to the device configuration register. Configuring a device or changing a variable device setting causes all the state and configuration values of the terminal node of the associated interface to be set to the default value. This includes setting the (date toggle) of the node that is being used (date toggle) to DATA0.

6) Suspend State
To conserve power, the USB device automatically enters the abort state when the bus transmission is not detected. When aborted, the USB device maintains its own internal state, including its address and configuration.
All devices must enter a stop state when they cannot detect bus activity for a specified period of time. Regardless of whether the device is assigned a non-default address or is configured, the connected device must be ready to abort at any time the power is added. The termination of the bus activity may be due to the host itself entering the abort state. In addition, the USB device must enter a stop state when the connected hub port fails. This is referred to as the Selective abort (selective suspend).
The USB device terminates the state when the bus activity comes. The USB device can also remotely wake up the current signal to request the host to exit the abort state or a selective abort state. The ability of a specific device to have remote wake-up is optional, that is, if a device has the ability to wake remotely, the device must be able to allow the host to control whether this capability is valid or not. The remote wake-up capability must be disabled when the device is reset.

2. Enumeration steps

The USB protocol defines 6 states of the device, and the device undergoes a 4-state migration during the enumeration process: power- up status (Powered), default state, address status, and configuration status (configured) (The other two are the connection state and the pending state (Suspend)).

2.1 The user plugs the USB device into the USB port or power on the device when the system starts

The USB port refers to the hub port on the root hub under the host or on the downstream port of the host. The hub supplies power to the port, and the connected device is in power-up state. At this point, the USB device is in a power-up state and the port it is connected to is not valid.

2.2 Hub monitors the voltage on each port's data cable (d+/d-)

On the hub side, the data cables d+ and D-all have a resistor resistance of 14.25k to 24.8k on the RPD, while on the device side, the d+ (full speed, high speed) and d (Low speed) have a 1.5k pull-up resistor RPU. When the device is plugged into the hub port, a data cable with a pull-up resistor is pulled up to a voltage of 90% of the amplitude (roughly 3V). The hub detects that one of its data lines is high, thinks there is a device plugged in, and can determine exactly what device (full speed/low speed) is plugged into the port (full speed, fast device distinction, as described in my future article), depending on whether it is d+ or D-pull. Such as.

USB full/High speed device power-on connection

When the device is detected, the hub continues to power the device, but is not in a hurry to transfer the USB to the device.

The USB interface is defined as shown in the following:

2.3 Host to learn about connected devices

Each hub uses its own interrupt endpoint to report the status of its various ports to the host (for this process, the device is invisible and does not care), and the reported content is just the device connection/disconnection event for the hub port. If a connection/disconnect event occurs, host sends a GET_PORT_STATUS request to the hub to understand the exact meaning of this state change. Requests such as Get_port_status belong to the Hub class standard request (Hub-class requests) that all hubs require support.

2.4 Hub detects whether the device is plugged into a high-speed or low-velocity device

The hub determines the speed type of the connected device by detecting the high and low voltages of the USB bus idle time difference line, and when host sends a GET_PORT_STATUS request, the hub can revert the device's speed type information to host. The USB 2.0 specification requires that speed detection be preceded by a reset operation.

2.5 Hub Reset Device

Once the host learns that the new device is connected, it waits at least 100ms to make the insertion operation complete and the device power stable. The host controller then sends a SET_PORT_FEATURE request to the hub to have the hub reset its managed port (the one just plugged into the device). The hub drives the data line to the reset state (d+ and D are all low) and lasts at least 10ms. Of course, the hub will not send such a reset signal to other existing devices connected to the port, so other devices connected to the hub naturally do not see the reset signal, unaffected.

2.6 Host detects if the connected full-speed device is in support of high mode

Because of the USB 2.0 protocol, high-speed devices operate at the initial full speed state, so for a high-speed hub that supports USB 2.0, when it discovers that its port is connected to a full-speed device, it detects high-speed, See if the device still supports high-speed transmission, and if so, cut to the high-speed signal mode, otherwise it will be working at full speed.
Similarly, from a device's point of view, if it is a high-speed device, it can only be run with full-speed signal mode when the bub is connected or power up (according to the USB 2.0 protocol, the high-speed device must be backwards compatible with the USB 1.1 full-speed mode). The hub will then perform a high-speed inspection before the device switches to high-speed mode. If the connected hub does not support USB 2.0, which is not a high speed hub and cannot be detected at high speed, the device will always work at full speed.

2.7 Hub establishes the information channel between the device and the host

The host continuously sends a GET_PORT_STATUS request to the hub to inquire if the device is reset successfully. The report information returned by the Hub has a special one used to mark the device's reset status.
When the hub revokes the reset signal, the device is in the default/idle state, ready to receive requests from the host. Communication between the device and the host is performed by controlling the transmission, default address 0, and endpoint number 0. At this point, the maximum current that the device can get from the bus is 100mA. ( all USB devices have an address of 0 after the bus reset, so the host can communicate with the device that was just plugged in by address 0 .) )

2.8 Host sends a GET_DESCRIPTOR request to get the maximum packet length for the default pipe

The default pipe, at the end of the device, is endpoint 0. The host is sending a request at this point is the default address 0, endpoint 0, although all Unassigned address devices are to obtain the host from the address of the request, but because the enumeration process is not multiple devices parallel processing, but one time to enumerate a device, so there will not be multiple devices at the same time to respond to requests from the host.
The 8th byte of the device descriptor represents the maximum packet size for device endpoint 0. Although the device descriptor returned by the device is only 18 bytes long, the system does not care, at which point the length information of the descriptor is the most important, and the other glance is over. When the first control transfer is completed, that is, the state phase of the control transmission, the system will ask the hub to reset the device again (the USB specification is not required). The purpose of re-resetting is to enable the device to enter a certain state.

2.9 Host assigns an address to the device

The host controller assigns a unique address to the device through the set_address request. After the transfer is complete, the device enters the address state, and then enables the new address to continue communicating with the host. This address is for a lifetime device, device in, address in; device disappears (unplugged, reset, System restart), address is retracted. The same device is not necessarily the last one when it gets enumerated again.

2.10 Host gets information about the device

The host sends the Get_descriptor request to the new address to read the device descriptor, this time the host sends the Get_descriptor request can be considered sincere, it will carefully parse the device descriptor content. The information in the device descriptor includes the maximum packet length for the endpoint 0, the number of configurations supported by the device, the device type, the VID (Vendor ID, assigned by the Usb-if), the PID (Product ID, customized by the vendor), and so on. Get_descriptor request (device type) and device descriptor (erased vid,pid information) See:

Standard Get_descriptor Request

Equipment Descriptor (device descriptor)
The host then sends Get_descriptor requests, reads the configuration descriptor (config descriptor), strings, and so on, to understand the device more detailed information. In fact, in a standard request for a configuration descriptor, sometimes wlength is larger than the actual configuration descriptor Length (9 bytes), such as 255. This effect is: The host sends a get_descriptor_configuration request, the device will be the interface descriptor, the end descriptor and other subsequent descriptors back to the host, the host is based on the descriptor head of the flag to determine what the specific descriptor is sent.
Next, the host gets the configuration descriptor. The configuration descriptor is 9 bytes in total. After the host gets to the configuration descriptor, it gets the configuration collection based on the total length of the configuration collection inside. The configuration collection includes configuration descriptors, interface descriptors, endpoint strokes, and so on.
If you have a string descriptor, you also get the string descriptor. In addition HID device also has HID descriptor and so on.

2.11 Host to device Mount driver (except for composite devices)

By parsing the descriptor, the host has sufficient knowledge of the device and chooses the most appropriate driver for the device. Then tell the world (Announce_device) that the device has been found, and finally call the device model provided by the interface Device_add add the device to the USB bus device list, then the USB bus will traverse each driver in the drive list, call its own The match (usb_device_match) function looks at whether they match your device or interface, calls the Device_bind_driver function if it matches, and now controls the power to the device driver.

For composite devices, it should usually be different interfaces (INTERFACE) configured for different drivers, so it is necessary to wait until the device is configured and the interface is enabled before the drive can be mounted.
Device-Configuration-interface-endpoint relationship see:

USB Device-Configuration-interface-endpoint Relationship
The actual situation does not have such a complicated relationship. In general, a device is a configuration, an interface, if the device is a multi-functional compliance device, there are multiple interfaces. Endpoints typically have several, such as mass storage devices typically have two endpoints (except control endpoint 0).

2.12 Device driver Select a configuration

Drive (Note that here is the driver, after the thing is there is a driver to take charge of communication with the device) according to the information of the previous device reply, send set_ The configuration request formally determines which of the selected devices is configured as a work configuration (typically only one configuration is defined for most devices). At this point, the device is in the configured state (configured), and of course, the device should also enable its various interfaces (Interface).
For composite devices, the host will mount the driver at this time based on the device interface information.

3. Control Transmission Control transmission is the most important and most complex type of transport, which uses a 8-byte size of the DATA0 packet, the 8-byte packet is the host used to send Control PhaseAnd these request commands are key to the host configuration of the USB device.

1) Bmrequesttype (request to whom)

D7: Transmission Direction
0= host to device; 1 = device to host
D6. 5: Command type d6d5=00: Standard request command; D6D5=01: class request command; d6d5=10: User-defined command; d6d5=11: Reserved.

D4. 0: Recipient Type 0 = device; 1= interface;
2= end point; 3 = Other
4..31 retains this field to indicate the nature of this request. In particular, this field indicates the second phase of the control transmission direction. If the wlength domain is set to 0, indicating that there is no data transfer phase, the direction bit is ignored.
The USB description defines a series of standard requests that all devices must support. These requests are shown in the table below <standard Device requests>. In addition, a device class can define more requests. Device vendors can also define requests that are supported by the device.
The request can be directed to a device, device interface, or a device end node (endpoint). This request domain also specifies the recipient. When an interface or end junction (endpoint) is specified, the Windex field indicates that interface or end node.
2) Bmrequest (what request)This domain identifies a particular request. The Type field of the Bmrequesttype domain modifies the meaning of this field. This article only defines the meaning of the Brequest domain value when the Type field is 0, which is a standard device request. 3) Wvalue Domain
This field is used to transfer the parameters of the current request and varies with the request.
4) Windex domain
When the Bmrequesttype recipient field is an interface or an endpoint, the Windex field is used to indicate which interface or end knot is.
5) Wlength domain
This field indicates the second phase of the data transfer length. The transmission direction is indicated by the direction bit of the Bmrequsttype domain. A wlength field of 0 indicates no data transfer. The data returned by the device should not be more than wlength at the input request, but can be less than. Under Output requests, wlength indicates the exact amount of data sent by the host. If the host sends more than wlength of data, the response from the device is undefined. 3.1 Standard device Request 3.2 standard request code (value of Brequest) 3.3 Descriptor Type 3.4 get_descriptor (read descriptor) This request returns the existence of the Descriptor. wvalue Domain:Tall byte: Identity description Table Type (descriptor Types) Low one byte: The index that represents the description symbol, when you apply several types of the same descriptor to the device, the descriptor index is used to select a specific descriptor (only configuration and string descriptors). For example, a device can use several configuration descriptors. For other standard descriptors that can be obtained through the GetDescriptor () request, the index of the descriptor must be 0. Descriptor index values range from 0 to the number of devices that use the type descriptor minus 1.
Windex Domain:Identifies the language of the String description table (Language ID), which is set to 0 if it is in a different language. wlength Domain:Indicates how many bytes to return. If the description table is longer than the Wlength field value, only the initial part of the description table is returned. If the description table is smaller than the Wlength field value, a short packet is sent to flag the end of the transfer.       A short package is defined as a length shorter than the maximum payload length or an empty (NULL) package. This standard request consists of 3 descriptors: The device (that is, the device qualifier), the configuration (that is, other speed configurations), and the string.       Devices capable of high-speed operation support the device qualifier descriptor returns information about the speed that the device does not support (including the wmaxpacketsize of the default endpoint and the number of other speed configurations). Other speed configurations return information with the same structure as the configuration descriptor, but return configuration information if the device operates at a different speed.       The request configuration descriptor returns the configuration descriptor, all interface descriptors, and endpoint descriptors for all interfaces in this request. A device request for the first interface descriptor returns a description table for the Configuration Description table, all interface descriptions, and the end nodes of all interfaces. The first interface descriptor follows the configuration descriptor followed by the descriptor of the end node of the first interface. If there are other interfaces and end nodes, their descriptions Fu Yi followed by the first interface and the end node descriptor. A class-related descriptor, and/or vendor-defined descriptor followed by a standard descriptor.
All devices must provide a device descriptor and at least one configuration descriptor, and if a device does not support a request descriptor, a request error is returned.
• Default state: This request is valid.
• Address Status: This request is legal.
• Configuration Status: This request is valid.
3.5 get_interface (Get interface) This request returns the selected standby device to the specified interface.
Some USB devices have interface settings for mutually exclusive configurations. This request allows the host to determine the currently selected alternate settings. If the value of Wvalue or wlength is inconsistent with the specified above, then the behavior of the device is undefined, and if the specified interface does not exist, the device responds with a request error.
• Default state: The device's behavior is not defined when it receives the request when the device is in the default state
• Address Status: The device gives a request error
• Configuration Status: This is a valid request when the device is in the configured state

USB enumeration Process "Go"