A USB hub is responsible for recognizing attachment and removal of peripheral devices on its downstream ports. Each USB hub has an interrupt IN endpoint for reporting these types of events directly to the host (which in most cases in your laptop or desktop computer). Whenever you boot up your operating system, USB hubs immediately inform the host if any devices are currently attached to it, including additional downstream USB hubs and any peripheral devices that may be attached to them.
After you’ve booted up your system, the host will continue to look for connected devices either by polling periodically on the USB 2.0 specification or by receiving ERDY Transaction Packets (SuperSpeed) that request communications to learn of any newly attached or removed USB devices.
Once your system discovers a new peripheral device, the host will send requests to the device hub to cause it to establish a direct communication path between the host and the device. From there, the host will then attempt to enumerate the peripheral device by issuing control transfers that contain standard USB requests to the device. All USB devices registered by the USB-IF must support control transfers, (the standard requests), by returning requested information and taking other requested actions alongside it.
From an outsider’s perspective, the enumeration process goes unnoticed and is an automatic occurrence with the exception of possibly a message that pops up on your operating system alerting you of a new device connection and whether the attempt to configure it was successful or not. On some rare occasions with more complicated peripheral devices, the user will sometimes need to select a drive or tell the host where exactly to look for driver files. But that’s the most interaction you’ll have with the enumeration process.
On a Windows PC, the new device will appear in the Device Manager whenever the enumeration process has completed. To access this folder, you go right click on the Computer icon, click Manage, and in the Computer management section you select the Device Manager. When a user removes a peripheral device from the bus, the device will disappear from the Device Manager entirely. In a typical device, firmware will decode and respond to requests for more information. Some controllers can manage enumeration entirely in hardware except possibly for vendor provided values in EEPROM. On the host side of things, the operating system handles the enumeration process entirely.
The Enumeration Process States
For this tutorial we will be using the USB 2.0 specification as an example. Although in actuality, this process differs very little than the newer USB 3.0 specification, it is important that we make this distinction. The USB 2.0 specification is defined as one of six device states.
During the enumeration process, a peripheral device moves through the Powered, Default, Address, and Configured states. The other two states are defined as either Attached or Suspend. Each of these states is unique and has certain defined capabilities and behaviors.
The following processes describe a typical sequence of events that occur during the enumeration process of a USB 2.0 device operating under the Windows host system. The device firmware does not assume that any enumeration requests and events will occur in any particular order. In order to function successful, a device must first detect and respond to any control request or other bus event at any time.
The very first thing that should happen is a user connects a common peripheral device such as a keyboard or mouse to a USB port. The system may power up with the device attached depending on the peripheral. The port may be on the root hub at the host or on a USB hub that connects downstream from the host. The USB hub provides power to the USB port, and the peripheral device is in the Powered state. The device can then draw up to 100 mA from the bus. (Keep in mind this is under the USB 2.0 specification).
Next the hub will detect the device. The hub will monitor 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 D- for a low-speed device. High-speed-capable devices attach at full speed.
The peripheral’s pull up brings its line high and this enables the hub to detect that a device is attached to it. Once the device is detected, the hub continues to provide power but doesn’t yet transmit USB traffic to the peripheral.
Upon learning of a new peripheral device the host uses each hub at its interrupt endpoints to report events at the hub. This report will only show whether or not the hub or a port has experienced an event. In addition, the host will send the hub a Get Port Status request to find out more information about the peripheral device. Get Port Status and the other hub-class requests described are standard requests that all hubs support. The information returned tells the host when a device is newly attached.
From here, the hub will detect whether a device is low or full speed. Just before resetting the USB device, the hub will find out whether the device is low or full speed by examining the voltages on the tow signal lines. The hub will find the device speed by figuring out which line has a higher voltage when it is idle. The hub then sends this information to the host in response to the next Get Port Status request that is sent. The USB 2.0 specification requires that speed detection be sent before the reset so that the hub knows whether or not to check for a high speed capable device during a reset.
Now the hub will reset the device. When a host discovers 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 10ms. Reset is a special state where both D+ and D- are logic low, as opposed to having opposite logic states under normal conditions. The hub sends the reset only to the new peripheral device. Other hubs and devices on the hubs don’t see the reset.
Next the host will learn if whether or not the full speed device supports a high speed connection. Detecting whether a peripheral device supports high speed requires 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 requests at full speed.
The hub will then establish a signal path between the device and the bus. The host verifies that the device has excited the reset state by sending a Get Port Status request. A bit in the returned data will show whether the device is still present in the reset state. If at all necessary, the host repeats the request until the device has exited the reset state entirely.
Once the hub removes the reset state, the device will be in the Default state. The device USB registers are in their reset states at this point, and the device is ready to reply to control transfers at endpoint zero. The device will then communicate with the host using the default address of 00h.
The host will send a Get Descriptor request in order to find out the maximum packet size of the default pipe. The host sends the request to device address 00h, endpoint zero. Because the host enumerates only one device at a time, only one device will actually respond to communications addressed to device address 00h even if multiple devices are attached at once.
The eighth byte of the device descriptor contains the maximum packet size supported by endpoint zero. A Windows host requests 64 bytes but after receiving just one packet (whether or not it has 64 bytes), the host launches the Status stage of the transfer. Once the Status stage is finished, Windows requests that the hub reset the device as described earlier. 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.
The host will then assign an address to the peripheral device. Once the reset is completed, the host controller will assign a unique address to the device by sending a Set Address control request. The peripheral device finishes the Status stage of the request using the default address and then launches the new address. The device will then be in the Address state. From this point forward, all communications between the host and the device will be through the newly established address. This address is valid until the device is detached, a hub resets the port, or the system itself reboots. On the next enumeration process (disconnects and reconnects of the same device) the host may or may not assign a different address entirely to the device.
Next up the host will learn about what the device does. In other words, what purpose does the device serve to the host? The host will send a Get Descriptor request to the new address to read the device descriptor. This time around the host will retrieve the entire descriptor. The descriptor hold the maximum packet size for endpoint zero, the number of configurations the device supports, and other basic information about the device.
The host will continue to learn about the device in question by requesting multiple configuration descriptors specified in the device descriptor itself. These requests are actually followed by all of its subordinate descriptors up to the number of bytes requested. On the Windows operating system, the host will begin by requesting just the configuration descriptor’s nine bytes. Included here are the total length of the configuration descriptor and its subordinate descriptors.
Windows will then request for the configuration descriptor again, but this time it will request the number of bytes in the retrieved total length. The device will respond by sending the configuration descriptor followed by all of the configuration’s subordinate descriptors, including interface descriptors, with each interface descriptor followed by any endpoint descriptors for the interface. Some configurations also have class- or vendor-specific descriptors. This chapter has more on what the descriptors contain.
Now the host will assign and load a device driver. After figuring out more about a device from its descriptors, the host will look for the best match in a driver to manage any further communications with the peripheral 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. 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 the driver, the driver may request the device to resend descriptors or send other class-specific descriptors.
Finally the host device driver will select a configuration for the peripheral. After it figures out more information about the device from its descriptors, the device driver will request a configuration by sending a Set Configuration request with the desired configuration number. Many peripheral devices will only support one configuration.
But if for any reason a device can support multiple configurations, the driver can then decide which configuration to request for based upon the information the driver has about how the device will ultimately be used by the host, or in some cases the driver can also ask the user what to do or just select the first configuration available. Upon 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.
The hubs themselves 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.
The final two states of the USB enumeration process are the Attached and Suspend. 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. A device enters the Suspend state after detecting no bus activity, including SOF markers, for at least 3ms. In the Suspend state, the device should limit its use of bus power. Both configured and unconfigured devices must support this state. Chapter 16 has more about the Suspend state.
So remember, take the opportunity to affordable-papers.net write.
may be wondering what sort of advice you are going to require so as to locate the research papers that you want.