당신은 주제를 찾고 있습니까 “usb enumeration – Training – USB 101 – Introduction to USB“? 다음 카테고리의 웹사이트 https://hu.taphoamini.com 에서 귀하의 모든 질문에 답변해 드립니다: https://hu.taphoamini.com/photos/. 바로 아래에서 답을 찾을 수 있습니다. 작성자 Silicon Labs 이(가) 작성한 기사에는 조회수 77,962회 및 좋아요 770개 개의 좋아요가 있습니다.
Table of Contents
usb enumeration 주제에 대한 동영상 보기
여기에서 이 주제에 대한 비디오를 시청하십시오. 주의 깊게 살펴보고 읽고 있는 내용에 대한 피드백을 제공하세요!
d여기에서 Training – USB 101 – Introduction to USB – usb enumeration 주제에 대한 세부정보를 참조하세요
USB 101 – Introduction to USB. This the class you need to understand and get started with the universal serial bus interface.
http://community.silabs.com/t5/Video-Tutorials/USB-101-Introduction-and-everything-you-need-to-know-about/m-p/139228#U139228
Easily implement USB in your designs
Pre-programmed with all the necessary USB software
No need to be familiar with the USB specification
Seamless compatibility with most operating systems
Evaluation kits available to support your design
usb enumeration 주제에 대한 자세한 내용은 여기를 참조하세요.
Simplified Description of USB Device Enumeration – FTDI
USB Enumeration is the process of detecting, entifying and loading drivers for a USB device. This involves a mixture of hardware …
Source: ftdichip.com
Date Published: 4/10/2021
View: 1585
USB Enumeration – Perytech
USB enumeration is the process of USB device recognition by the host. An example of explaining USB enumeration is as follows: Imagine that a traveler wishes to …
Source: www.perytech.com
Date Published: 5/25/2022
View: 4850
USB Enumeration – Developer Help
Enumeration is the process whereby the Host detects the presence of a Device and takes the necessary steps to ensure that the Device endpoints are added to the …
Source: microchipdeveloper.com
Date Published: 12/21/2022
View: 639
What is Enumeration and Why are USB Descriptors Important?
Enumeration within a USB system is a process where the host detects the presence of a device, determines what type of device is connected, …
Source: www.totalphase.com
Date Published: 8/21/2021
View: 7040
USB Enumeration Implementation on the AT8xC5131/32/22 …
Implementing the USB Enumeration Process on … known as bus enumeration to entify and manage the device state changes necessary. When a USB device is …
Source: ww1.microchip.com
Date Published: 6/10/2021
View: 2802
How does USB stack enumerate a device?
Port resets of all USB devices are serialized via an “enumeration lock” on a per host controller basis, as only one USB device can be enabled …
Source: techcommunity.microsoft.com
Date Published: 11/11/2021
View: 9936
USB Enumeration Explained – USBTrace
The enumeration process can be dived into 2 phases: Phase #1, where the host learns about the newly arrived device by reading the descriptors and loads the …
Source: www.sysnucleus.com
Date Published: 7/24/2022
View: 4948
Troubleshooting Basic USB Enumeration Problems
Another useful tool that can help debug USB enumeration problems is a free program from Microsoft called USB Device Viewer. This software can be …
Source: community.silabs.com
Date Published: 8/6/2021
View: 8053
Enumeration: How the Host Learns about Devices
The USB 2.0 specification defines six device states. During enumeration, a device moves through the Powered, Default, Address, and Configured states. (The other …
Source: janaxelson.com
Date Published: 6/29/2022
View: 6276
주제와 관련된 이미지 usb enumeration
주제와 관련된 더 많은 사진을 참조하십시오 Training – USB 101 – Introduction to USB. 댓글에서 더 많은 관련 이미지를 보거나 필요한 경우 더 많은 관련 기사를 볼 수 있습니다.
주제에 대한 기사 평가 usb enumeration
- Author: Silicon Labs
- Views: 조회수 77,962회
- Likes: 좋아요 770개
- Date Published: 2015. 2. 4.
- Video Url link: https://www.youtube.com/watch?v=5S6ZPmtPzRA
USB Enumeration
USB Enumeration
In this article, we use universal serial bus (USB) communication data recorded by a logic analyzer to illustrate the USB enumeration process.
Index
A USB is the most common and successful computer interface. Learning about the USB is imperative for electronics engineers.
This article illustrates USB enumeration. USB enumeration is the process of USB device recognition by the host.
First, USB enumeration is one of the most important USB technologies. USB devices must complete the enumeration process to connect with hosts. USB product development engineers must understand USB enumeration before they can correctly design USB firmware.
Second, learning USB enumeration by only reading books is difficult. Almost all books on USB present the USB enumeration process by using various tables. Although these tables contain essential USB enumeration information, beginners find it difficult to understand USB enumeration if they only study these tables.
The purpose of this article is to provide supplemental information beyond that in books, thus allowing users to easily understand USB enumeration. We analyze USB communication data recorded by a logic analyzer to illustrate the USB enumeration process. Observing actual data is easier than studying tables in a book to understand USB enumeration.
Our focus on USB enumeration does not mean that other parts of USB are not vital. However, several books that illustrate USB technology are already available. Therefore, repeating the same information in our article is unnecessary. Because of length constraints, we have omitted basic USB knowledge. If you are unfamiliar with USB technology, we recommend that you read about it from a book or relevant documents. This article will simplify the USB enumeration chapter.
USB enumeration is the process of USB device recognition by the host. An example of explaining USB enumeration is as follows: Imagine that a traveler wishes to stay at a hotel. To ensure that a suitable room is arranged for him or her, the hotel service staff must ask the traveler a few questions to determine his or her preferred room.
The conversation between the traveler and hotel staff might proceed as follows:
Hotel service staff: “How many people will be staying?”
Traveler: “One.”
Hotel service staff: “Would you like a room with a sea view or with a mountain view?”
Traveler: “I would like a room with a sea view.”
Hotel service staff: “Would you like a shower or a bathtub?”
Traveler: “A shower.”
……
……
After asking relevant questions, the hotel service staff can select a preferred room for the traveler. USB enumeration consists of a similar process. Once USB devices are connected to hosts, the hosts query to identify the types and needs of the devices. After the questions have been answered, the hosts determine whether they can be connected to the devices. If so, drivers are assigned to the devices to complete USB enumeration.
USB has two data transmission wires, namely D+ and D−. To measure USB communication, a user must connect the D+, D−, and ground (GND) wires to a logic analyzer. Peeling the skin of the USB cable reveals four wires—red, black, green, and white wires. The red, black, green, and white wires represent the power supply wire, GND, D+, and D−, respectively. To connect the USB to the logic analyzer, we peeled the black, green, and white wires (do not cut them off) and then connected them to the logic analyzer.
Alternatively, you can purchase a USB adapter board from Perytech. The adapter board connects USB wires to pins to facilitate measurements. The adapter board is very simple; you can construct an adapter board.
The device under test is a USB keyboard. We first connected channels A0 and A1 of the logic analyzer to D+ and D−, respectively, as displayed in the following image.
When the USB device is plugged into the host, USB enumeration begins immediately. Therefore, logic analyzer software must be set up before plugging the USB keyboard into the host. Next, the compression mode of the logic analyzer is turned on. USB enumeration takes a while. For instance, the USB keyboard took approximately 1 s to complete the USB enumeration. To measure the longtime signal, we enabled the compression mode of the logic analyzer. We set the sampling rate to 200 MS/s and the trigger condition to the A0 rising edge trigger.
We clicked “Run” after ensuring that everything was set. Because the USB device was not connected to the host, D+ and D− did not have signals and the logic analyzer was not triggered. After plugging the USB keyboard into the host, USB communication triggered the logic analyzer, which then began recording the data.
The recorded USB signals are depicted in the following image. The recording time was approximately 1.3 s. If no compression mode exists, a sampling rate of 200 MS/s can be used to record 1.3 s. Each channel requires 260 MB of memory.
On zooming, we can observe that at the beginning of communication, the D+ and D− signals were in a low voltage state for more than 10 ms during two time periods. These two time periods were reset signals that the USB hub sent to the USB device. For USB 2.0 high-speed devices, the reset signal is sent only once.
Zooming in further, we can observe start-of-frame packets (SOFs), which are indicated by the yellow box in the following figure. These SOFs were sent at the beginning of each frame. For USB 1.1, the period of each frame is 1 ms. In the following figure, the interval between two SOFs is approximately 998.66 µs. The SOF interval plus the width of the SOF (approximately 1.34 μs) is 1 ms.
Zooming in even further, we can observe the packet content, which is depicted in the following figure. Observing signals and packets simultaneously provides us a deep understanding of USB signals. However, to save time, the “Packet List” function is a suitable choice for viewing packets. Click on “Tool” → “Packet List” to open the packet list.
The contents displayed on the screen after opening the Packet List function are depicted in the following figure. The Packet List function lists all the packet data. This allows users to view packet data more easily.
These packets contain USB enumeration information. To interpret these packets, the USB specification can be referred. The USB specification referenced in this document is USB 2.0, which is available for download at usb.org.
A brief explanation of the USB communication format is provided. When a host needs to access a USB device (e.g., read data from a USB hard disk), the USB driver divides this request into one or more “Transactions.” A Transaction is the unit of USB data transmission, and each transaction comprises 2–3 USB packets. The first packet of the transaction is the token packet, which is used to indicate the type of transaction. If the transaction involves data transmission, then the second packet is the data packet. The direction of data transmission between a host and a USB device can be from the host to the USB device or from the USB device to the host. Not all transactions have data packets. Have data packets or not and the transmission direction of the data packet all depends on the token packet.
The last packet of the Transaction is the handshake packet. The receiver (host or the USB device) uses the packet to feedback whether correct data is obtained.
The three packets of the following figure form the first transmission. The packet number in the yellow box on the left is generated by the logic analyzer to assist users in viewing the desired packets quickly. The green box in the first packet contains the token (i.e., “setup”). Because the USB device is not yet assigned the “address” and “endpoint” value, the address and endpoint values of this setup packet are both zero.
The second USB packet is the data packet. This causes the data to be passed from the host to the USB device. To analyze the data in the data packet, users must refer to the section “Format of Setup Data” and Table 9-2 in the USB specification. The meaning of each byte is explained in the table.
Offset Field Size Value Description 0 bmRequestType 1 Bitmap Characteristics of request:
D7: Data transfer direction
0 = Host-to-device
1 = Device-to-host
D6…5: Type
0 = Standard
1 = Class
2 = Vendor
3 = Reserved
D4…0: Recipient
0 = Device
1 = Interface
2 = Endpoint
3 = Other
4…31 = Reserved 1 bRequest 1 Value Specific request 2 wValue 2 Value Word-sized field that
varies according to request 4 wIndex 2 Index or Offset Word-sized field that varies
according to request; typically
used to pass an index or offset 6 wLength 2 Count Number of bytes to transfer
if there is a Data stage
Format of Setup Data. Source: USB 2.0 Specification Table 9-2
Byte 0 is a bmRequestType, and its value signifies the properties of the request. The bmRequestType function is divided into three parts—recipient, type, and data transfer direction. The logic analyzer automatically splits the bmRequestType into three fields. A recipient field value of 0 denotes “Device,” and a type field value of 0 denotes “Standard.” The data transfer direction (Dir) field is D→H, that is, the direction of data transmission is from the device to the host.
Byte 1 is a bRequest and has a value of 0 × 06, as indicated in Table 9-4 (i.e., Standard Request Codes) of the USB specification. According to the table, 0 × 06 is GET_DESCRIPTOR. Thus, the request is GET_DESCRIPTOR.
bRequest Value GET_STATUS 0 CLEAR_FEATURE 1 Reserved for future use 2 SET_FEATURE 3 Reserved for future use 4 SET_ADDRESS 5 GET_DESCRIPTOR 6 SET_DESCRIPTOR 7 GET_CONFIGURATION 8 SET_CONFIGURATION 9 GET_INTERFACE 10 SET_INTERFACE 11 SYNCH_FRAME 12
Standard Request Codes. Source: USB 2.0 Specification Table 9-4
Bytes 2–7 are the fields for wValue, wIndex, and wLength. Each field is 2-bytes wide, and its meaning varies according to the request received. In this example, the request is GET_DESCRIPTOR. In Section 9.4.3 of the USB specification, the meanings of the three fields when the request is GET_DESCRIPTOR are explained (presented in the following table).
bmRequestType bRequest wValue wIndex wLength Data 10000000B GET_DESCRIPTOR Descriptor Type
and
Descriptor Index Zero or
Language ID Descriptor
Length Descriptor
Get Descriptor. Source: USB 2.0 Specification
The high byte in wValue (value is 0 × 01) represents the descriptor type. The meaning of this value can be obtained from Table 9-5 of the USB specification. According to the table, a value of 1 signifies DEVICE. In other words, the type of the descriptor is DEVICE.
Descriptor Types Value DEVICE 1 CONFIGURATION 2 STRING 3 INTERFACE 4 ENDPOINT 5 DEVICE_QUALIFIER 6 OTHER_SPEED_CONFIGURATION 7 INTERFACE_POWER 8
Descriptor Type. Source: USB 2.0 Specification
The third packet is ACK and is a response from the USB device to indicate that the data has been received correctly.
USB Packets 4 and 5 are In and NAK, respectively, as displayed in the following figure. The two packets form one transaction. Because this transaction contains no transmission data, only two packets are present. The USB IN and OUT are from the perspective of the host. In other words, IN indicates that the host wishes to read data from the USB device. The USB device’s response of NAK does not indicate a data error but rather that no data is available for transmission. The USB device is required to issue a response even if no data is available for transmission. If the USB device does not issue a response for some time, the USB device is assumed to be disconnected by the host. Because NAK packets contain no data, they are generally skipped in analysis.
The host continues to send In packets to request for data, and the USB device responds in the ninth packet. The response data contains 18 bytes separated into three data packets. The reason for separation is that in this transmission mode, each packet can contain a maximum of only 8 bytes. The content of the three packets is illustrated in the following figure.
These data are explained as follows. GET_DESCRIPTOR and DEVICE are the request and type functions, respectively. Thus, the data requested by the host are the device descriptors. The data format and description of the device descriptors are presented in Table 9-8.
Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor in bytes 1 bDescriptorType 1 Constant DEVICE Descriptor Type 2 bcdUSB 2 BCD USB Specification Release Number in Binary-Coded Decimal. 4 bDeviceClass Class 1 Class code (assigned by the USB-IF). 5 bDeviceSubClass 1 SubClass Subclass code (assigned by the USB-IF). 6 bDeviceProtocol 1 Protocol Protocol code (assigned by the USB-IF). 7 bMaxPacketSize0 1 Number Maximum packet size for endpoint zero (only 8, 16, 32, or 64 are valid) 8 idVendor 2 ID Vendor ID (assigned by the USB-IF) 10 idProduct 2 ID Product ID (assigned by the manufacturer) 12 bcdDevice 2 BCD Device release number in binary-coded decimal 14 iManufacturer 1 Index Index of string descriptor describing manufacturer 15 iProduct 1 Index Index of string descriptor describing product 16 iSerialNumber 1 Index Index of string descriptor describing the device’s serial number 17 bNumConfigurations 1 Number Number of possible configurations
Standard Descriptor Type. Source: USB 2.0 Specification
The aforementioned table represents the flow of the host reading the device descriptor of the USB device. However, enumeration is not completed. To complete USB enumeration, the following five steps must be conducted:
1. The host reads the Device Descriptor from the USB device.
2. The host assigns an address for the USB device.
3. The host reads the Configuration Descriptor from the USB device.
4. The host reads the Interface Descriptor from the USB device.
5. The host reads the Endpoint Descriptor from the USB device.
The analyzed USB packet previously is step one. The analysis methods for the other steps are similar. Therefore, the description is not repeated. Because the order of the enumeration commands is random, the USB devices must be able to respond to any command at any time. Sometimes, a host may read a descriptor repeatedly.
A USB device has only one device descriptor but can have multiple configurations. The number of configurations is defined in a device descriptor. Each configuration can have multiple interfaces. The number of interfaces is defined in a configuration descriptor. Each interface may have multiple endpoints. The number of endpoints is defined in an interface descriptor. Overall, USB enumeration features a hierarchical data structure similar to that of a tree diagram. The top layer is the device descriptor, followed by the configuration, interface, and endpoint descriptors.
A demonstration mode is available in logic analyzer software, which allows the use of software without a logic analyzer. Please visit our web page to download the software. The software contains a file that records the USB enumeration process. You can use logic analyzer software to load this file for observing the USB enumeration process. By observing the USB enumeration process and referring to the USB specification document, you will understand USB enumeration.
After understanding how USB enumeration functions, how should one start writing a USB enumeration program? In general, writing a USB program is similar to filling a USB data table. A CPU with a USB interface possesses a USB controller. The USB controller submits data to the host during the enumeration process to accomplish USB enumeration.
The format of the enumeration data table for each USB controller is not necessarily the same. Some tables are designed using the C language, and others are designed using assembly languages. Most USB IC companies provide sample codes. An example code of the Device Descriptor is listed as follows:
code uint8 DeviceDescriptor[0x12] =
{
/* bLength */
0x12,
/* bDescriptorType */
0x01,
/* bcdUSB */
0x10,
0x01,
/* bDeviceClass */
0x00,
/* bDeviceSubClass */
0x00,
/* bDeviceProtocol */
0x00,
/* bMaxPacketSize0, the pdiusbd12 chip has a maximize size of 16 */
0x10,
/* idVender, just for test, for commercial use, you should apply for it from the usb association */
0xF3,
0x04,
/* idProduct */
0x03,
0x01,
/* bcdDevice, version number of product */
0x07,
0x01,
/* iManufacturer */
0x00,
/* iProduct */
0x00,
/* iSerialNumber */
0x00,
/* bNumConfigurations, the number of configurations of a device, most device have only one configuration */
0x01
};
The compression function of logic analyzers is key to measuring USB signals. The difference between using and not using the function is demonstrated in the following image. The first figure illustrates the USB signals measured without using the compression function. Here, we set the memory size to 64 k and the sampling rate to 200 MS/s. The recording time was approximately 327.67 µs.
The packet list recorded only four packets.
Next, a logic analyzer produced by a different manufacturer was tested. This logic analyzer has a maximum compression rate of 256. The test conditions were the same as before, and the recording time was approximately 40.478 ms.
The packet list recorded 20 packets, which is still insufficient. USB keyboards require at least 400 USB packets to complete USB enumeration. The 20 packets recorded were only 1/20 of the required amount.
Finally, the Perytech logic analyzer was tested. The test conditions were the same as before, and the recording time was approximately 3.36 s.
With the Perytech logic analyzer, 1680 packets were recorded in the packet list. This logic analyzer has a maximum compression rate of 1 million. The test result revealed that the compression mode substantially improved the recording time.
We used USB 1.1 to illustrate USB enumeration. Although USB 3.1 is now available, USB 1.1 is more suitable for learning USB enumeration because of the following reasons. First, USB 1.1 is the basis of all USB specifications. USB 2.0 is the extension of USB 1.1, and its structure is very similar to that of USB 1.1. Therefore, if you are familiar with USB 1.1, you can understand USB 2.0 in a short time. Although USB 3.0 contains additional features, it still needs to be compatible with USB 2.0 and USB 1.1. Thus, the engineer who learns USB 3.0 must also understand USB 2.0 and 1.1.
Second, USB 1.1 comprises a cheaper and wider selection of chips than USB 2.0 does. Many low-end 8-bit processors have built-in USB 1.1, whereas only a few have built-in USB 2.0. Moreover, chips with built-in USB 2.0 are more expensive than chips with built-in USB 1.1. Because of the high speed of USB 2.0, impedance matching requirements for the PCB and wires are high. This increases the PCB costs and development time. By contrast, the requirements for USB 1.1 are less stringent and hardware design is less difficult.
In terms of speed, USB 3.0 is more suitable in applications where large amounts of data must be transmitted. However, most controls require the transmission of only a small amount of data. To this day, the RS232 with Baud Rate 19200 (19200 bits per second) is still very common in industrial control, and USB 1.1 with a speed of 12 M is sufficient.
Finally, USB 2.0 analysis instruments are markedly expensive and in the price range from thousands of dollars to ten thousands of dollars. Thus, beginners may not be able to purchase them. For analyzing USB 1.1 signals, only Perytech logic analyzers are required. A single Perytech analyzer costs less than $100. The Perytech logic analyzer is powerful, and analyzing the USB is only one of its features.
USB Enumeration
Enumeration is the process whereby the Host detects the presence of a Device and takes the necessary steps to ensure that the Device endpoints are added to the list of endpoints serviced by the Host.
Device Enumeration States
Device Detection
The presence of a newly installed Full Speed, High Speed, or Low Speed Device is recognized by changes in the D- or D+ signal. A low-speed device places 5 V on D-, high- and full-speed devices assert 5 V on D+. The connection signals are detected by the Hub and reported to the Host. Once a Device is detected, the Host issues a RESET command to the Device.
Default State
When a RESET control signal sequence is received, the Device will manage its load, per specification, to enumerate. If the attached Device is a High-Speed device, a “chirp” will be returned and the High-Speed detection process will be completed. Once the speed has been settled, the Host reads the Device descriptor and assigns an address.
Addressed State
After setting the address, the Host reads all remaining descriptor tables for the device. If a Host determines it can service the Device’s interface endpoints and provide sufficient power, the Host issues a command informing the Device which of its configurations to activate.
Configured State
After receiving notification from the Host regarding which configuration to activate, the Device is ready to run using the active configuration.
What is Enumeration and Why are USB Descriptors Important?
The USB Protocol
The USB protocol was introduced in 1996 as a way to institutionalize a more widespread, uniform cable and connector that could be used across a multitude of different devices. The idea was to simplify the connection of devices to and from a host computer. The protocol is currently maintained and regulated by the USB Implementors Forum or better know as USB-IF. This group sets standards that all USB devices must follow in order to be compliant with the technology and work properly across all USB compatible devices.
USB has a wide range of device types. Whether a user is plugging in a mouse and keyboard or connecting a flash memory drive, the process remains simple and seamless. The USB specification was written specifically to provide this plug and play user experience. This experience is made possible by the USB enumeration process.
Picture of mouse and keyboard by bongkarn thanyakij from Pexels
What is Enumeration?
Enumeration within a USB system is a process where the host detects the presence of a device, determines what type of device is connected, and defines the speed at which to communicate. This process is important because different types of USB devices will communicate or interact with the host differently.
Referring back to the computer mouse and flash memory device, once connected to a host, these devices will behave differently because they have different functions. A mouse is a human interface device designed to provide a method for a user to interact with the host. This device operates entirely different from a memory device such as a flash drive. A flash drive is used to read and write data to and from the computer. The memory device and mouse are different USB devices, yet the host computer knows how to interact with each device because of the USB device descriptors sent to the host during the enumeration process. The enumeration process goes through nine main steps as seen in the graphic below.
USB Enumeration Process
What are USB Descriptors?
USB descriptors are presented to the host during the enumeration process. These descriptors tell the host what type of device is connected and how to properly communicate with it. There are four types of descriptors: Device Descriptors, Configuration Descriptors, Interface Descriptors, and Endpoint Descriptors.
Device Descriptor
Each USB device can only have a single Device Descriptor. This descriptor contains information that applies globally to the device, such as serial number, vendor ID, product ID, etc. The device descriptor also has information about the device class. The host PC can use this information to help determine what driver to load for the device.
Configuration Descriptor
A device descriptor can have one or more configuration descriptors. Each of these descriptors defines how the device is powered (e.g. bus-powered or self-powered), the maximum power consumption, and what interfaces are available in this particular setup. The host can choose whether to read just the configuration descriptor or the entire hierarchy (configuration, interfaces, and alternate interfaces) at once.
Interface Descriptor
A configuration descriptor defines one or more interface descriptors. Each interface number can be subdivided into multiple alternate interfaces that help more finely modify the characteristics of a device. The host PC selects a particular alternate interface depending on what functions it wishes to access. The interface also has class information which the host PC can use to determine what driver to use.
Endpoint Descriptor
An interface descriptor defines one or more endpoints. The endpoint descriptor is the last descriptor in the configuration hierarchy and it defines the bandwidth requirements, transfer type, and transfer direction of an endpoint. For transfer direction, an endpoint is either a source (IN) or sink (OUT) of the USB device.
Loading USB Drivers
Once these descriptors are shared, the host then loads the proper drivers needed to operate the device. USB driver files are installed on the host and provide the information that allows proper communication with the variety of USB device classes. These driver files provide the details to interpret the device descriptors to seamlessly interact with the USB device. Most USB devices are from a common specification-defined class and can rely on a standard driver that is automatically pulled and installed without the user knowing it. However, with custom USB class devices, the user may need to download a special driver, provided by the developer, to successfully communicate with the USB device.
USB Device Classes
Why is USB Enumeration Important?
The enumeration process is a vital part of the USB architecture. Since USB has such a diverse set of device types, it is important that the host has a way to define how to communicate properly with each individual device. The enumeration process ensures that every USB connected device is recognized by the host to ensure proper data transfer. Without enumeration, a host is unable to define the device type and what type of data transfer to use, the interval at which to send data, or even the speed of communication.
Debugging the Enumeration Process
Total Phase has a variety of USB tools to help developers debug the enumeration process. In most USB debugging, developers find themselves running into issues when it comes to their devices not communicating with the host device as intended. Total Phase offers a line of Beagle USB Protocol Analyzers that can help provide information on why the enumeration process may corrupted.
All of the Total Phase Beagle USB Protocol Analyzers capture and trace the enumeration process with great detail. Whether working with Low or SuperSpeed USB there is an analyzer to help. One of the most common Total Phase USB protocol analyzers is the Beagle USB 5000 v2 SuperSpeed Protocol Analyzer.
Beagle USB 5000 v2 SuperSpeed Protocol Analyzer
The Beagle USB 5000 v2 SuperSpeed Protocol Analyzer non-intrusively monitors SuperSpeed/High-/Full-/Low-Speed USB traffic up to 5 Gbps. The Standard edition can monitor either USB 2.0 or USB 3.0 traffic, while the Ultimate edition can monitor USB 2.0 and USB 3.0 traffic simultaneously. This analyzer offers real-time display, search, and filtering of captured data, along with descriptor and USB class decoding. It also offers users the ability to perform USB 2.0/USB 3.0 advanced triggering with flexible state-based conditions on data patterns, packet types, error types, events, and other criteria. Additionally, it provides enhanced visibility into the USB 3.0 bus, detecting low-level bus events including link training, LFPS polling, training sequences, and provides a view into the LTSSM which tracks upstream and downstream link state transitions.
Descriptor Decoding on the Beagle USB v2 5000 Protocol Analyzer
The Beagle USB v2 5000 analyzer captures early, low-level bus events including the enumeration process. Combined with the Data Center Software, users can see all of the enumeration information in decoded format. For instance, take a look at the information below of the captured from the Beagle USB 5000 v2 analyzer and displayed by the Data Center Software from a USB computer mouse. The Data Center software logs information on all four of the main USB descriptor data packets as seen in the images below.
Device Descriptor in the Data Center Software
Configuration Descriptor in the Data Center Software
Interface Descriptor in the Data Center Software
Endpoint Descriptor in the Data Center Software
Understanding the enumeration process is one of the single most important aspects of the USB protocol. It is also one of the most challenging aspects of implementing a USB device and can quickly cause problems in the development cycle. The proper enumeration of USB devices is an absolute must when it comes to USB and having the right tools to debug is essential.
For more information on how Total Phase interfaces with the USB bus, check out our USB product page. To see one of our USB analyzers in action, check out this video of our Beagle USB 5000 v2 Protocol Analyzer sniffing a USB 3.0 flash memory device.
How does USB stack enumerate a device?
Hello, my name is Martin Borve. I am a software developer on the Windows USB team. In this post I will provide a detailed description of the enumeration process used by the Windows 7 core USB driver stack – from the point the stack detects a presence of device to the point it indicates to the PnP manager that a new device has arrived.
Device enumeration for a USB port begins when the hub indicate a connect status change via the hub’s interrupt endpoint. If the port status indicates a newly connected device, the USB hub driver will use the following sequences of steps to enumerate the device:
Let us find out in detail how the software stack interacts with the device in each of these steps by describing which hardware events are handled, which ones are ignored, how long the software waits for the next event to occur, when does the software attempt reenumeration, how many times it reattempts, what constitutes a broken device, what leads to enumeration failure, etc.
The steps 1 through 7 are required for the device to be enumerated and reported to the system. In the next blog post, I will summarize all the hardware issues during enumeration that can either cause the software stack to not report the device at all or report to the system as “Unknown Device” by providing “USB\VID_0000&PID_0000” as the Device ID.
NOTE: Enumeration information provided here applies to 1.1 and 2.0 devices. The sequence and timing of various operations may change for 2.1+ and 3.0+ devices.
Port Stabilization Debounce
The hub driver must observe a period of at least 100ms where there are no port connect changes (USB 2.0 spec, 7.1.7.3, TATTDB). If the port has not stabilized after 200ms, the hub driver will disable the port and cancel enumeration. No device will be reported to PnP.
First Port Reset
Once the port debounce has completed successfully, the hub driver will issue a reset request for the port. In normal operation this will result in the port status transitioning to a connected and enabled state, and the device itself will respond to the default USB address of 0.
Port resets of all USB devices are serialized via an “enumeration lock” on a per host controller basis, as only one USB device can be enabled with the default USB address 0 at a any one time. The hub driver will acquire the enumeration lock prior to issuing the first port reset request, and will release it when the device has been assigned a non-default USB address, or when enumeration has been cancelled. The hub driver uses a 5 second timeout for the port reset request in case it never completes.
While waiting for the first port reset to complete, the hub driver must be able to deal with the following events:
Device Disconnect
Enumeration is cancelled. No device is reported to PnP.
Overcurrent Change
Enumeration is normally cancelled in this case, unless the over-current is determined to be spurious. No device is reported to PnP.
Timeout of Port Reset
In the case of a timeout of the first reset request, the hub driver will attempt to retry enumeration up to 3 times by returning to the beginning of the “First Port Reset” state. A delay of 500ms occurs between each retry to allow the device to settle. If the port reset times out on the 3rd retry, enumeration will be cancelled and an “Unknown Device” will be reported to PnP.
If the port reset request completes successfully, the hub driver will proceed based on the current port state as follows:
Device Disconnected
Enumeration is cancelled. No device is reported to PnP.
Port Connected and Disabled
Port reset completion is ignored. Reset timeout will be allowed to run, and port reset will be retried as appropriate.
Port Connected and Suspended
Enumeration is cancelled. No device is reported to PnP.
Port Overcurrent
Port reset completion is ignored. Reset timeout will be allowed to run, and port reset will be retried as appropriate.
Port Enabled and Connected
This indicates a successful reset of the port. The hub driver delays at least 10ms to allow for reset recovery (USB 2.0 spec, 7.1.7.3, TRSTRCY). The hub driver moves to the “First Device Descriptor Request” state.
First Device Descriptor Request
The USB driver stack issues a request for the USB Device Descriptor (GET_DESCRIPTOR for Descriptor Type DEVICE), using the default USB address of 0, and a maximum packet size of 8 bytes for low-speed devices and 64 bytes for full and high-speed devices.
This descriptor request is used solely to determine the correct maximum packet size for the default control endpoint, as specified in the Device Descriptor’s bMaxPacketSize0 field at offset 7. USB devices are required to return at least the first 8 bytes of the Device Descriptor when they are at the default USB address (USB 2.0 spec, 5.5.3).
When requesting the device descriptor the hub driver will specify a transfer size of 64 bytes. This is done because some older USB devices will behave badly if the request size is smaller. We’ve also found some USB devices will babble when returning the device descriptor, but will still return valid data in at least the first 8 bytes. For this reason transfer errors will be ignored if at least 8 bytes of data were returned by the device.
If the request for the device descriptor fails, the hub driver will retry enumeration up to three times by returning to the “First Port Reset” state. If the hub driver has already retried enumeration 3 times, enumeration will be cancelled and an “Unknown Device” will be reported to PnP.
If the device descriptor request succeeds, the hub driver will move to the “Second Port Reset” step. All further control transfers for the default endpoint will use the maximum packet size specified in the Device Descriptor.
Second Port Reset
In the early days of USB some USB devices would become confused by a second request for the Device Descriptor if they did not return the complete Device Descriptor for the first request. To allow these devices to enumerate successfully it was necessary to reset the port between the first and second requests for the Device Descriptor.
The hub driver uses a 5 second timeout for the second port reset request in case it never completes. While waiting for the second port reset to complete, the hub driver must be able to deal with the following events (this is essentially identical to the handling in the first reset request):
Device Disconnect
Enumeration is cancelled. No device is reported to PnP.
Overcurrent Change
Enumeration is cancelled. No device is reported to PnP.
Timeout of Port Reset
In the case of a timeout of the second reset request, the hub driver will attempt to retry enumeration up to 3 times by returning to the beginning of the “First Port Reset” state. If the port reset times out on the 3rd retry, enumeration will be cancelled and an “Unknown Device” will be reported to PnP.
If the port reset request completes successfully, the hub driver will proceed based on the current port state as follows:
Device Disconnected
Enumeration is cancelled. No device is reported to PnP.
Port Connected and Disabled
Port reset completion is ignored. Reset timeout will be allowed to run, and port reset will be retried as appropriate.
Port Connected and Suspended
Enumeration is cancelled. No device is reported to PnP.
Port Overcurrent
Port reset completion is ignored. Reset timeout will be allowed to run, and port reset will be retried as appropriate.
Port Enabled and Connected
This indicates a successful reset of the port. The hub driver delays at least 10ms to allow for reset recovery (USB 2.0 spec, 7.1.7.3, TRSTRCY). The hub driver moves to the next enumeration state “Set USB Address”. The hub driver will delay 100ms after successfully resetting the port if enumeration had to be retried at least once.
Set USB Address
The USB driver stack allocates a unique (per-controller) USB device address and issues a SET_ADDRESS request to the device. If the SET_ADDRESS request fails or times out, enumeration is cancelled and an “Unknown Device” is reported to PnP.
If the SET_ADDRESS is successful, the hub driver will wait for at least 10ms to allow for device stabilization before moving to the “Second Device Descriptor Request” state.
Second Device Descriptor Request
The USB driver stack will issue a second request for the full USB Device Descriptor (GET_DESCRIPTOR for Descriptor Type DEVICE). If the request fails or times out, the port is disabled and enumeration is retried by returning to the “First Port Reset” state. If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.
Upon successful completion of the second request for the Device Descriptor, the hub driver will validate the Device Descriptor as follows:
The bLength field is equal to or greater than the size of a USB Device Descriptor, as defined in the USB 2.0 specification.
field is equal to or greater than the size of a USB Device Descriptor, as defined in the USB 2.0 specification.
The bDescriptorType field is equal to descriptor type DEVICE (1).
If the validation fails, the port is disabled and enumeration is retried by returning to the “First Port Reset” state. If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.
Upon successful validation of the Device Descriptor, the hub driver will cache the descriptor, release the enumeration lock, and move to the “Configuration Descriptor Request” state.
Configuration Descriptor Request
The USB driver stack will issue a request for the device’s USB Configuration Descriptor (GET_DESCRIPTOR for Descriptor Type CONFIGURATION). For compatibility reasons the configuration descriptor request will specify a length of 255 bytes.
If the Configuration Descriptor request completes with an error or times out, the hub driver will disable the port and retry enumeration by returning to the “First Port Reset” state. If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.
If the Configuration Descriptor request completes successfully, the hub driver will verify that the number of bytes returned for the request is greater than or equal to the Configuration Descriptor’s wTotalLength value. If it is not greater than or equal to wTotalLength , the hub driver will retry the Configuration Descriptor request once to insure the device is not returning invalid data in the descriptor.
Upon successful completion of the Configuration Descriptor request, the USB driver stack will validate the descriptor as follows:
The bLength field is equal to or greater than the size of a USB Configuration Descriptor, as defined in the USB 2.0 specification.
field is equal to or greater than the size of a USB Configuration Descriptor, as defined in the USB 2.0 specification.
The bDescriptorType field is equal to descriptor type CONFIGURATION (2).
If the validation fails the hub driver will disable the port and retry enumeration by returning to the “First Port Reset” state. If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.
If the validation is successful, the Configuration Descriptor is cached and the hub driver moves on to the “MS OS Descriptor Query” state.
MS OS Descriptor Query
Microsoft has defined a set of vendor specific USB descriptors called Microsoft OS Feature Descriptors , which are queried for at the time of device enumeration.
If the USB Device Descriptor’s bcdUSB field is equal to 0x0100 or 0x0110, the hub driver will skip the query for the MS OS Descriptor and move to the “Serial Number String Descriptor Query” state.
If the hub driver has never before enumerated a device with the same VID/PID/Revision as the device being enumerated, it will query the device for the MS OS String Descriptor (GET_DESCRIPTOR for Descriptor Type STRING), which uses index 0xEE. It will specify a language ID of 0x00.
If the device returns an MS OS Descriptor, the hub driver will validate the descriptor as follows:
The MicrosoftString field must be equal to “MSFT100”.
Once validated, the value in the descriptor’s bVendorCode field will be stored in the registry on a per VID/PID/Revision basis, under the USBFLAGS registry subkey in the “osvc” registry value. Subsequent enumerations of any device with the same VID/PID/Revision will read the bVendorCode from this registry value rather than querying the device.
The hub driver will then move to the “Serial Number String Descriptor Query” state.
Serial Number String Descriptor Query
If the USB Device Descriptor reports a non-zero serial number string index, the hub driver will query for the serial number string descriptor (GET_DESCRIPTOR for Descriptor Type STRING) using the American English language ID (0x409) and the serial number string index.
The hub driver performs the following validation on all string descriptors:
The number of bytes returned for the request must be greater than or equal to the bLength field.
The number of bytes returned for the request must be greater than or equal to the bLength field.
The bLength field must be larger than 2 bytes.
The bDescriptorType field must be equal to descriptor type STRING (3).
The bLength field must be an even number, as the string is a Unicode string.
If this validation passes, the hub driver performs the following validation specifically for the serial number string descriptor:
The string is non-NULL.
The string is not longer than 255 bytes.
The descriptor type returned in the descriptor is type STRING.
The number of bytes in the string is an even number, as it’s a Unicode string.
The string does not contain any invalid characters:
The character must have a value greater than or equal to 0x20.
The character must have a value less than or equal to 0x7F.
The character must not be a comma (‘,’=0x2C).
If any of the above validation fails the serial number will be discarded, otherwise it will be cached.
Regardless of the results of the serial number query and validation, the hub driver will move on to the “MS OS Extended Configuration Descriptor Request” state if the device supports the MS OS Descriptor, otherwise it will move to the “Language ID Query”.
MS OS Extended Configuration Descriptor Request
If the device is not a composite device the hub driver will issue a request for the MS OS Extended Configuration Descriptor.
Software will issue an initial request for this descriptor by specifying a data size equal to the descriptor’s header. This will be used to determine the existence of the descriptor, and to determine its size. If the request is successful the hub driver will validate the header as follows:
The returned number of bytes must be equal to the defined size of the header.
The binary-coded decimal header version field must be 1.00.
The header’s wIndex field must be set to 4.
The header’s bCount field must be non-zero.
The header’s dwLength field must be equal to the size of the header, plus the value of the bCount field times the size of the configuration descriptor’s function structure.
Once the descriptor header is validated, the hub driver will re-issue the request for the descriptor using the size of the entire descriptor as returned by the device in the descriptor’s header.
If a device successfully returns an MS OS Extended Configuration Descriptor, the hub driver will validate the descriptor as follows:
The standard USB configuration descriptor will be parsed for functions described by Interface Association Descriptors and single-interface functions to determine the total number of functions on the device.
The following validation will be performed on the MS OS Extended Configuration Descriptor Header:
The header’s dwLength value must be greater than or equal to the size of the header structure.
The header’s dwLength value must be less than or equal to the size of the header plus 256 Extended Configuration Descriptor functions.
The header’s dwLength value must be less than or equal to the number of bytes returned by the device for the descriptor.
The header’s wIndex value must equal 4, the MS Extended Configuration Descriptor Index.
The header’s bCount value must be less than or equal to the number of functions that were found in the USB Configuration Descriptor.
The header’s dwLength value must be greater than or equal to the size of the header structure plus the header’s bCount times the size of the Extended Configuration Descriptor Function structure.
The following validation will be performed on each function descriptor:
bFirstInterfaceNumber is less than or equal to 256.
bFirstInterfaceNumber corresponds to the first interface of a function described by an Interface Association Descriptor or a single-interface function in the device’s USB Configuration Descriptor.
The CompatibleID string only contains upper-case ASCII characters(“A”-“Z”), numbers(“0”-“9”), and/or the underscore character (“_”).
The SubCompatibleID string only contains upper-case ASCII characters(“A”-“Z”), numbers(“0”-“9”), and/or the underscore character (“_”).
The number of function descriptors must be equal to the bCount value in the header.
Software will move to the “MS OS Container ID Descriptor Query” state.
MS OS Container ID Descriptor Query
Windows 7 introduces the concept of a Container ID , which is used to group all functions that are part of a physical device. For details on how USB generates Container IDs, please refer to this whitepaper.
If the VID/PID/Revision of the device has been previously flagged as not supporting the Container ID Descriptor via the registry, the hub driver will move to the “Language ID Query” state.
If neither the hub descriptor nor the ACPI namespace describes the device as non-removable, and the device supports the MS OS Descriptor, the USB stack will query the device for the MS OS Container ID, otherwise the hub driver will move to the “Language ID Query” state.
A device must indicate support for the container ID by setting bit 1 of the bFlags flag of the MS OS Descriptor. If this bit is set, software will issue a request for the MS OS Container ID Descriptor header. The setup packet will specify a wIndex of 6, and the Device as the recipient. If a descriptor is successfully returned, the hub driver will validate the descriptor as follows:
The returned number of bytes must equal the size of the MS OS Container ID Descriptor header.
The MS OS Container ID Descriptor header’s bcdVersion must be 0x100.
The MS OS Container ID Descriptor header’s wIndex must be 6.
The MS OS Container ID Descriptor header’s dwLength must be equal to the size of a MS OS Container ID Descriptor.
If the header is successfully validated, software will issue a request for the entire MS OS Container ID Descriptor. The setup packet will again specify a wIndex of 6, and the Device as the recipient.
If the descriptor is successfully returned, the hub driver will validate the descriptor as follows:
The returned number of bytes is equal to the defined size of the MS OS Container ID Descriptor
The Container ID is not all zeros.
If the request for the Container ID Descriptor fails for any reason, a registry value will be set to indicate the hub driver should skip this request in future enumerations of devices with the same VID/PID/Revision. The hub driver will then disable the port and retry enumeration by returning to the “First Port Reset” state. If the hub driver has already retried enumeration 3 times, enumeration is cancelled and an “Unknown Device” is reported to PnP.
Language ID Query
The USB hub driver will query the device for the array of supported language IDs. The hub driver will issue a query for the string descriptor at index 0, which is an array of 2-byte LANGID codes supported by the device, as defined in section 9.6.7 of the USB 2.0 specification.
The hub driver will perform standard string descriptor validation on the Language ID string descriptor, as described previously in the description of the “Serial Number String Descriptor Query” state. If the string is found to be valid, the hub driver will cache the data returned in the string. It will then move to the “Product ID String Query” state.
Product ID String Query
If the USB Device Descriptor’s iProduct field is non zero the hub driver will issue a request for the Product ID string using the string index specified in the iProduct field and the English language ID of 0x409.
If the string descriptor request completes successfully, the hub driver will perform standard string descriptor validation on the Product ID string descriptor. If the validation is successful, the hub driver will cache the string. It will then move to the “Device Qualifier Descriptor Query” state.
Device Qualifier Descriptor Query
If the device is attached to a USB 1.1 hub, is operating at Full-Speed, and its USB Device Descriptor bcdUSB field is greater than or equal to 0x200, the hub driver will issue a GET_DESCRIPTOR for descriptor type DEVICE_QUALIFIER (6).
The successful completion of the request indicates the device can support USB 2.0 high-speed operation.
Duplicate Device Detection
The USB driver stack must deal with an artifact of the EHCI companion controller design where a device can move quickly between the USB 2.0 EHCI host controller and a companion USB 1.1 controller when the USB 2.0 controller is enabled or disabled. This creates a scenario where the new instance of a USB device can be reported to the PnP Manager before its previous instance on the other host controller had been reported as removed to PnP Manager. This results in a bugcheck if the device has a serial number, as PnP Manager would see two device nodes reporting the same unique instance IDs. This behavior can also occur when a USB device is moved to a different port while the system is suspended.
The USB hub driver maintains a list of all USB devices currently attached to the system and have been reported to the PnP Manager. If the currently enumerating device has a serial number, software will search this list for any device that has the same vendor ID, product ID, revision number, and serial number. If no matching device is found, the hub driver will move to the “Report New Device To PnP Manager” state.
If a matching device is found the hub driver will handle it based the following logic:
If the matching device and enumerating device are on the same port, it is a case where the device quickly detached/re-attached (possible a spurious connect change). No action is taken, as the previous instance will be reported as removed at the same time the new instance is reported as arrived to PnP Manager.
If the matching device is detected as being no longer physically present, software will delay 5 seconds, waiting for the matching device to be reported to PnP Manager as removed. If the matching device is not reported as removed at the end of the delay, the port is disabled and enumeration is retried by returning to the “First Port Reset” state. If software has already retried enumeration 3 times, the port is disabled and enumeration is cancelled. No device will be reported to PnP Manager.
If the matching device is still physically present, it is a case of two identical devices with the same serial number. In this case the serial number for newly enumerated device will be discarded, to prevent PnP Manager from triggering a bugcheck.
Report New Device to PnP Manager
At this point the USB device has been successfully enumerated and the hub driver will report the new device to PnP. This involves calling IoInvalidateDeviceRelations and reporting then new device when handling IRP_MN_QUERY_DEVICE_RELATIONS/BusRelations.
USB Enumeration Explained
Introduction
This article explains the USB Enumeration process as seen by USBTrace. For a more general explanation see USB Complete : Enumeration. USBTrace is a software only USB Protocol Analyzer which can be used to debug the entire enumeration process. Unlike some other software analyzers USBTrace does not use any filter drivers to capture USB bus activity. The limitation with using a filter driver is that you cannot start logging until the driver for the device is loaded. So such monitoring software will miss the USB requests exchanged between the host and the device before the driver for the device is loaded.
How to setup USBTrace to monitor enumeration ?
After starting USBTrace, click the Capture Hot Plugged Devices menu or toolbar button and start capture. Plug in the device and USBTrace will start capturing all requests exchanged between host and the newly plugged in device. Click Stop Capture to end the capture session.
Enumeration Log Walkthrough
The enumeration process can be divided into 2 phases: Phase #1 , where the host learns about the newly arrived device by reading the descriptors and loads the appropriate device driver & Phase #2 , where the device driver configures the device and makes it ready for data transfer.
Fig Phase #1
As shown above, in the first phase the host learns about the device by reading its device, configuration and string descriptors. With USBTrace, detailed information regarding each of these requests can be obtained.
Fig Phase #2
The second phase starts with the loaded driver of the device getting an IRP_MN_START_DEVICE PNP IRP. After this, the driver reads the device, configuration and string descriptors and configures the device by selecting a configuration. The device is now ready for data transfer.
If you want to see the requests exchanged between the host and the hub during phase #1 of device enumeration, check the hub (root hub or external hub) to which the device is plugged in before starting capture. This includes the host reading the port status and resetting the port.
Related Links
1. Handling the IRP_MN_START_DEVICE PnP IRP
2. USB Complete: Enumeration
3. USB in a Nutshell: Enumeration
Jan Axelson’s Lakeview Research
Home > USB Complete > From Chapter 4
From Chapter 4
Enumeration: How the Host Learns about Devices
One of a hub’s duties is to detect attachment and removal of devices on its downstream-facing ports. Each hub has an interrupt IN endpoint for reporting these events to the host. On system boot-up, hubs inform the host if any devices are attached including additional downstream hubs and any devices attached to those hubs. After boot-up, a host continues to poll periodically (USB 2.0) or receives ERDY TPs (Enhanced SuperSpeed) that request communications to learn of any newly attached or removed devices.
On learning of a new device, the host sends requests to the device’s hub to cause the hub to establish a communications path between the host and device. The host then attempts to enumerate the device by issuing control transfers containing standard USB requests to the device. All USB devices must support control transfers, standard requests, and endpoint zero. For a successful enumeration, the device must respond to requests by returning requested information and taking other requested actions.
From the user’s perspective, enumeration is invisible and automatic but may display a message that announces the new device and whether the attempt to configure it succeeded. Sometimes on first use, the user needs to assist in selecting a driver or telling the host where to look for driver files. Under Windows, when enumeration is complete, the new device appears in the Device Manager. (Right-click Computer, click Manage, and in the Computer Management pane, select Device Manager.) On detaching, the device disappears from Device Manager. In a typical device, firmware decodes and responds to received requests for information. Some controllers can manage enumeration entirely in hardware except possibly for vendor-provided values in EEPROM or other memory. On the host side, the operating system handles enumeration.
Getting to the Configured state
The USB 2.0 specification defines six device states. During enumeration, a device moves through the Powered, Default, Address, and Configured states. (The other defined states are Attached and Suspend.) In each state, the device has defined capabilities and behavior.
Typical USB 2.0 sequence
The steps below are a typical sequence of events that occurs during enumeration of a USB 2.0 device under Windows. Device firmware shouldn’t assume that enumeration requests and events will occur in a particular order. Different OSes and different OS editions might use a different sequence. To function successfully, a device must detect and respond to any control request or other bus event at any time as required by the USB specifications. Figure 4-1 shows received requests and other events during a device enumeration.
1. The system has a new device. A user attaches a device to a USB port, or the system powers up with a device attached. The port may be on the root hub at the host or on a hub that connects downstream from the host. The hub provides power to the port, and the device is in the Powered state. The device is in the Attached state and can draw up to 100 mA from the bus.
2. The hub detects the device. The hub monitors the voltages on the signal lines (D+ and D-) at each of its ports. The hub has a pull-down resistor of 14.25k–24.8kW on each line. A device has a pull-up resistor of 900–1575W on D+ for a full-speed device or on D- for a low-speed device. High-speed-capable devices attach at full speed. On attaching to a port, the device connects to the bus by bringing the appropriate pull-up line high so the hub can detect that a device is attached. Except for some devices with weak or dead batteries, the device must connect within 1 s after detecting that VBUS is at least 0.8 V. A device can continue to draw 100 mA of bus current for 1 s after connecting regardless of whether the upstream bus segment is suspended. On detecting a device, the hub continues to provide power but doesn’t yet transmit USB traffic to the device. Chapter 16 has more on how hubs detect devices.
3. The host learns of the new device. Each hub uses its interrupt endpoint to report events at the hub. The report indicates only whether the hub or a port (and if so, which port) has experienced an event. On learning of an event, the host sends the hub a Get Port Status request to find out more. Get Port Status and the other hub-class requests used during enumeration are standard requests that all hubs support. The information returned tells the host when a device is newly attached.
4. The hub detects whether a device is low or full speed. Just before resetting the device, the hub determines whether the device is low or full speed by detecting which signal line has a higher voltage when idle. The hub sends the information to the host in response to the next Get Port Status request. A USB 1.1 hub may instead detect the device’s speed just after a bus reset. USB 2.0 requires speed detection before the reset so the hub knows whether to check for a high-speed-capable device during reset as described below.
5. The hub resets the device. When a host learns of a new device, the host sends the hub a Set Port Feature request that asks the hub to reset the port. The hub places the device’s USB data lines in the Reset condition for at least 10 ms. Reset is a special condition where both D+ and D- are logic low. (Normally, the lines have opposite logic states.) The hub sends the reset only to the new device. Other hubs and devices on the bus don’t see the reset.
6. The host learns if a full-speed device supports high speed. Detecting whether a device supports high speed uses two special signal states. In the Chirp J state, only the D+ line is driven, and in the Chirp K state, only the D- line is driven.
During the reset, a device that supports high speed sends a Chirp K. A high-speed-capable hub detects the Chirp K and responds with a series of alternating Chirp K and Chirp J. On detecting the pattern KJKJKJ, the device removes its full-speed pull-up and performs all further communications at high speed. If the hub doesn’t respond to the device’s Chirp K, the device knows it must continue to communicate at full speed. All high-speed devices must be capable of responding to control-transfer requests at full speed.
7. The hub establishes a signal path between the device and the bus. The host verifies that the device has exited the reset state by sending a Get Port Status request. A bit in the returned data indicates whether the device is still in the reset state. If necessary, the host repeats the request until the device has exited the reset state.
When the hub removes the reset, the device is in the Default state. The device’s USB registers are in their reset states, and the device is ready to respond to control transfers at endpoint zero. The device communicates with the host using the default address of 0x00.
8. The host sends a Get Descriptor request to learn the maximum packet size of the default pipe. The host sends the request to device address 0x00, endpoint zero. Because the host enumerates only one device at a time, only one device will respond to communications addressed to device address 0x00 even if several devices attach at once.
The eighth byte of the device descriptor contains the maximum packet size supported by endpoint zero. The host may request 64 bytes but after receiving just one packet (whether or not it has 64 bytes), may begin the Status stage of the transfer.
On completing the Status stage, Windows may request the hub to reset the device as in step 5 above. The USB 2.0 specification doesn’t require a reset here. The reset is a precaution that ensures that the device will be in a known state when the reset ends. Windows 8 and later skip the second reset for high-speed devices because these devices typically don’t require a second reset. If enumeration fails without the second reset, Windows includes the reset on the next enumeration attempt.
9. The host assigns an address. When the reset is complete, the host controller assigns a unique address to the device by sending a Set Address request. The device completes the Status stage of the request using the default address and then implements the new address. The device is now in the Address state. All communications from this point on use the new address. The address is valid until the device is detached, a hub resets the port, or the system reboots. On the next enumeration, the host may assign a different address to the device.
10. The host learns about the device’s abilities. The host sends a Get Descriptor request to the new address to read the device descriptor. This time the host retrieves the entire descriptor. The descriptor contains the maximum packet size for endpoint zero, the number of configurations the device supports, and other information about the device.
The host continues to learn about the device by requesting the configuration descriptor(s) specified in the device descriptor. A request for a configuration descriptor is actually a request for the configuration descriptor followed by all of its subordinate descriptors up to the number of bytes requested.
If the host requests 255 bytes, the device responds by sending the configuration descriptor followed by all of the configuration’s subordinate descriptors, including interface descriptor(s), with each interface descriptor followed by any endpoint descriptors for the interface. Some configurations also have class- or vendor-specific descriptors.
One of the configuration descriptor’s fields is the total length of the configuration descriptor and its subordinate descriptors. If the value is greater than 255, the device returns 255 bytes. Windows then requests the configuration descriptor again, this time requesting the number of bytes in the total length specified in the configuration descriptor.
Earlier Windows editions began by requesting just the configuration descriptor’s nine bytes to retrieve the total length value, then requesting the complete descriptor set.
11. The host requests additional information from the device. The host then may request additional descriptors from the device. In every case, a device that doesn’t support a requested descriptor should return STALL.
When the device descriptor reports that the device is USB 2.1 or higher, the host requests a BOS descriptor. If the device returns the BOS descriptor, the host uses the descriptor’s total length value to request the BOS descriptor followed by its subordinate descriptor(s).
The host requests string descriptor zero, which contains one or more codes indicating what languages additional strings use.
If the device descriptor reports that the device contains a serial number string descriptor, the host requests that descriptor.
If the device descriptor indicates that the device contains a Product string descriptor, the host requests that descriptor.
For USB 2.0 and higher devices, if Windows doesn’t have a record of previously retrieving a Microsoft-specific MS OS string descriptor, the OS may request that descriptor.
If a BOS descriptor or a Microsoft OS string descriptor indicates support for additional Microsoft-defined descriptors, the host may request these descriptors.
For USB 2.0 or higher devices operating at full speed with an upstream USB 1.1 hub, the host requests a device qualifier descriptor. A device that returns this descriptor is capable of operating at high speed if all upstream ports are USB 2.0 or higher.
12. The host assigns and loads a device driver (except for composite devices). After learning about a device from its descriptors, the host looks for the best match in a driver to manage communications with the device. Windows hosts use INF files to identify the best match. The INF file may be a system file for a USB class or a vendor-provided file that contains the device’s Vendor ID and Product ID. Chapter 9 has more about INF files and selecting a driver.
For devices that have been enumerated previously, Windows may use stored information instead of searching the INF files. After the operating system assigns and loads a driver, the driver may request the device to resend descriptors or send other class-specific descriptors.
An exception to this sequence is composite devices, which can have different drivers assigned to multiple interfaces in a configuration. The host can assign these drivers only after enabling the interfaces, so the host must first configure the device as described below.
13. The host’s device driver selects a configuration. After learning about a device from the descriptors, the device driver requests a configuration by sending a Set Configuration request with the desired configuration number. Many devices support only one configuration. When a device supports multiple configurations, many drivers just select the first configuration, but a driver can decide based on information the driver has about how the device will be used, or the driver can ask the user what to do. On receiving the request, the device implements the requested configuration. The device is now in the Configured state and the device’s interface(s) are enabled.
For composite devices, the host can now assign drivers. As with other devices, the host uses the information retrieved from the device to find a driver for each active interface in the configuration. The device is then ready for use.
Hubs are also USB devices, and the host enumerates a newly attached hub in the same way as other devices. If the hub has devices attached, the host enumerates these after the hub informs the host of their presence.
Attached state. If the hub isn’t providing power to a device’s VBUS line, the device is in the Attached state. The absence of power may occur if the hub has detected an over-current condition or if the host requests the hub to remove power from the port. With no power on VBUS, the host and device can’t communicate, so from their perspective, the situation is the same as when the device isn’t attached.
Suspend State. A device enters the Suspend state after detecting no bus activity, including SOF markers, for at least 3 ms. In the Suspend state, the device should limit its use of bus power. Both configured and unconfigured devices must support this state. Chapter 17 has more about the Suspend state.
Enhanced SuperSpeed differences
[Note: Enhanced SuperSpeed is the USB 3.1 spec’s term for SuperSpeed and SuperSpeedPlus.]Enumerating Enhanced SuperSpeed devices has some differences compared to USB 2.0:
On detecting a downstream Enhanced SuperSpeed termination at a port, a hub initializes and trains the port’s link. Enumeration then proceeds at SuperSpeed or SuperSpeedPlus with no need for further speed detecting.
The host isn’t required to reset the port after learning of a new device.
The bus-current limits are 150 mA before configuration and 900 mA after configuration.
The host sends a Set Isochronous Delay request to inform the device of the bus delay for isochronous packets.
The host sends a Set SEL request to inform the device of the system exit latency (the amount of time required to transition out of a low-power state).
Protocols for entering and exiting the Suspend state differ.
For hubs, the host sends a Set Hub Depth request to set the hub-depth value.
Device removal
When a user removes a device from the bus, the hub disables the device’s port. The host knows that the removal occurred after the hub notifies the host that an event has occurred, and the host sends a Get Port Status request to learn what the event was. The device disappears from Device Manager and the device’s address becomes available to another newly attached device.
Tips for successful enumeration
Without successful enumeration, the device and host can’t perform other communications. Most chip companies provide example enumeration code that can serve as a model even if your application doesn’t exactly match the example application. If your controller interfaces to an external CPU, you may have to adapt code written for another chip.
In general, a device should assume nothing about what requests or events the host will initiate and should concentrate on responding to requests and events as they occur. The following tips can help avoid problems.
Don’t assume requests or events will occur in a specific order. Some requests, such as Set Configuration, require the device to be in the Address or Configured state so the request is valid only after the device has accepted a Set Address request. But the host has some flexibility in what requests to issue and in what order during enumeration. A host might also reset or suspend the bus at any time, and a device that has been connected for at least 1 s must detect the event and respond appropriately.
Be ready to abandon a control transfer or end it early. On receiving a new Setup packet, a device must abandon any transfer in progress and begin the new one. On receiving an OUT token packet (USB 2.0) or STATUS TP (Enhanced SuperSpeed), the device must assume that the host is beginning the Status stage of the transfer even if the device hasn’t sent all of the requested data in the Data stage.
Don’t attempt to send more data than the host requests. In the Data stage of a control read transfer, a device should send no more than the amount of data the host has requested. If the host requests nine bytes, the device should send no more than nine bytes.
Send a zero-length data packet when required. In some cases, the device returns less than the requested amount of data, and the amount of data is an exact multiple of the endpoint’s maximum packet size. On receiving a request for more data, the device should indicate that it has no more data by returning a ZLP (USB 2.0) or a zero-length Data Payload (Enhanced SuperSpeed).
Stall unsupported requests. A device shouldn’t assume it knows every request the host might send. The device should return STALL in response to any request the device doesn’t support.
Don’t set the address too soon. In a Set Address request, the device should set its new address only after the Status stage of the request is complete.
Be ready to enter the Suspend state. A host can suspend the bus when the device is in any powered state. Except within 1 s after the device connects, the device must reduce its use of bus power when the bus is in the Suspend state.
Test under different host-controller types. Devices should be able operate with any host controller that complies with the specifications. For example, some full-speed host controllers schedule multiple stages of a control transfer in a single frame, while others don’t. Devices should be able to handle either way.
키워드에 대한 정보 usb enumeration
다음은 Bing에서 usb enumeration 주제에 대한 검색 결과입니다. 필요한 경우 더 읽을 수 있습니다.
이 기사는 인터넷의 다양한 출처에서 편집되었습니다. 이 기사가 유용했기를 바랍니다. 이 기사가 유용하다고 생각되면 공유하십시오. 매우 감사합니다!
사람들이 주제에 대해 자주 검색하는 키워드 Training – USB 101 – Introduction to USB
- 동영상
- 공유
- 카메라폰
- 동영상폰
- 무료
- 올리기
Training #- #USB #101 #- #Introduction #to #USB
YouTube에서 usb enumeration 주제의 다른 동영상 보기
주제에 대한 기사를 시청해 주셔서 감사합니다 Training – USB 101 – Introduction to USB | usb enumeration, 이 기사가 유용하다고 생각되면 공유하십시오, 매우 감사합니다.
