
- •Chapter 1
- •1.1 Motivation
- •1.2 Objective of the Specification
- •1.3 Scope of the Document
- •1.4 Document Organization
- •Chapter 2
- •Chapter 3
- •3.1 Goals for the Universal Serial Bus
- •3.2 Taxonomy of Application Space
- •3.3 Feature List
- •Chapter 4
- •4.1 USB System Description
- •4.1.1 Bus Topology
- •4.2 Physical Interface
- •4.2.1 Electrical
- •4.2.2 Mechanical
- •4.3 Power
- •4.3.1 Power Distribution
- •4.3.2 Power Management
- •4.4 Bus Protocol
- •4.5 Robustness
- •4.5.1 Error Detection
- •4.5.2 Error Handling
- •4.6 System Configuration
- •4.6.1 Attachment of USB Devices
- •4.6.2 Removal of USB Devices
- •4.6.3 Bus Enumeration
- •4.7 Data Flow Types
- •4.7.1 Control Transfers
- •4.7.2 Bulk Transfers
- •4.7.3 Interrupt Transfers
- •4.7.4 Isochronous Transfers
- •4.7.5 Allocating USB Bandwidth
- •4.8 USB Devices
- •4.8.1 Device Characterizations
- •4.8.2 Device Descriptions
- •4.9 USB Host: Hardware and Software
- •4.10 Architectural Extensions
- •Chapter 5
- •5.1 Implementer Viewpoints
- •5.2 Bus Topology
- •5.2.1 USB Host
- •5.2.2 USB Devices
- •5.2.3 Physical Bus Topology
- •5.2.4 Logical Bus Topology
- •5.2.5 Client Software-to-function Relationship
- •5.3 USB Communication Flow
- •5.3.1 Device Endpoints
- •5.3.2 Pipes
- •5.4 Transfer Types
- •5.5 Control Transfers
- •5.5.1 Control Transfer Data Format
- •5.5.2 Control Transfer Direction
- •5.5.3 Control Transfer Packet Size Constraints
- •5.5.4 Control Transfer Bus Access Constraints
- •5.5.5 Control Transfer Data Sequences
- •5.6 Isochronous Transfers
- •5.6.1 Isochronous Transfer Data Format
- •5.6.2 Isochronous Transfer Direction
- •5.6.3 Isochronous Transfer Packet Size Constraints
- •5.6.4 Isochronous Transfer Bus Access Constraints
- •5.6.5 Isochronous Transfer Data Sequences
- •5.7 Interrupt Transfers
- •5.7.1 Interrupt Transfer Data Format
- •5.7.2 Interrupt Transfer Direction
- •5.7.3 Interrupt Transfer Packet Size Constraints
- •5.7.4 Interrupt Transfer Bus Access Constraints
- •5.7.5 Interrupt Transfer Data Sequences
- •5.8 Bulk Transfers
- •5.8.1 Bulk Transfer Data Format
- •5.8.2 Bulk Transfer Direction
- •5.8.3 Bulk Transfer Packet Size Constraints
- •5.8.4 Bulk Transfer Bus Access Constraints
- •5.8.5 Bulk Transfer Data Sequences
- •5.9 Bus Access for Transfers
- •5.9.1 Transfer Management
- •5.9.2 Transaction Tracking
- •5.9.3 Calculating Bus Transaction Times
- •5.9.4 Calculating Buffer Sizes in Functions and Software
- •5.9.5 Bus Bandwidth Reclamation
- •5.10 Special Considerations for Isochronous Transfers
- •5.10.1 Example Non-USB Isochronous Application
- •5.10.2 USB Clock Model
- •5.10.3 Clock Synchronization
- •5.10.4 Isochronous Devices
- •5.10.5 Data Prebuffering
- •5.10.6 SOF Tracking
- •5.10.7 Error Handling
- •5.10.8 Buffering for Rate Matching
- •Chapter 6
- •6.1 Architectural Overview
- •6.3 Cable
- •6.4 Cable Assembly
- •6.4.1 Detachable Cable Assemblies
- •6.4.3 Low-speed Captive Cable Assemblies
- •6.4.4 Prohibited Cable Assemblies
- •6.5.1 USB Icon Location
- •6.5.2 USB Connector Termination Data
- •6.5.3 Series “A” and Series “B” Receptacles
- •6.5.4 Series “A” and Series “B” Plugs
- •6.6.1 Description
- •6.6.2 Construction
- •6.6.3 Electrical Characteristics
- •6.6.4 Cable Environmental Characteristics
- •6.6.5 Listing
- •6.7 Electrical, Mechanical and Environmental Compliance Standards
- •6.7.1 Applicable Documents
- •6.8 USB Grounding
- •Chapter 7
- •7.1 Signaling
- •7.1.1 USB Driver Characteristics
- •7.1.2 Data Signal Rise and Fall
- •7.1.3 Cable Skew
- •7.1.4 Receiver Characteristics
- •7.1.5 Device Speed Identification
- •7.1.6 Input Characteristics
- •7.1.7 Signaling Levels
- •7.1.8 Data Encoding/Decoding
- •7.1.9 Bit Stuffing
- •7.1.10 Sync Pattern
- •7.1.11 Data Signaling Rate
- •7.1.12 Frame Interval and Frame Interval Adjustment
- •7.1.13 Data Source Signaling
- •7.1.14 Hub Signaling Timings
- •7.1.15 Receiver Data Jitter
- •7.1.16 Cable Delay
- •7.1.17 Cable Attenuation
- •7.1.18 Bus Turn-around Time and Inter-packet Delay
- •7.1.19 Maximum End-to-end Signal Delay
- •7.2 Power Distribution
- •7.2.1 Classes of Devices
- •7.2.2 Voltage Drop Budget
- •7.2.3 Power Control During Suspend/Resume
- •7.2.4 Dynamic Attach and Detach
- •7.3 Physical Layer
- •7.3.1 Regulatory Requirements
- •7.3.2 Bus Timing/Electrical Characteristics
- •7.3.3 Timing Waveforms
- •Chapter 8
- •8.1 Bit Ordering
- •8.2 SYNC Field
- •8.3 Packet Field Formats
- •8.3.1 Packet Identifier Field
- •8.3.2 Address Fields
- •8.3.3 Frame Number Field
- •8.3.4 Data Field
- •8.3.5 Cyclic Redundancy Checks
- •8.4 Packet Formats
- •8.4.1 Token Packets
- •8.4.2 Start-of-Frame Packets
- •8.4.3 Data Packets
- •8.4.4 Handshake Packets
- •8.4.5 Handshake Responses
- •8.5 Transaction Formats
- •8.5.1 Bulk Transactions
- •8.5.2 Control Transfers
- •8.5.3 Interrupt Transactions
- •8.5.4 Isochronous Transactions
- •8.6 Data Toggle Synchronization and Retry
- •8.6.1 Initialization via SETUP Token
- •8.6.2 Successful Data Transactions
- •8.6.3 Data Corrupted or Not Accepted
- •8.6.4 Corrupted ACK Handshake
- •8.6.5 Low-speed Transactions
- •8.7 Error Detection and Recovery
- •8.7.1 Packet Error Categories
- •8.7.2 Bus Turn-around Timing
- •8.7.3 False EOPs
- •8.7.4 Babble and Loss of Activity Recovery
- •Chapter 9
- •9.1 USB Device States
- •9.1.1 Visible Device States
- •9.1.2 Bus Enumeration
- •9.2 Generic USB Device Operations
- •9.2.1 Dynamic Attachment and Removal
- •9.2.2 Address Assignment
- •9.2.3 Configuration
- •9.2.4 Data Transfer
- •9.2.5 Power Management
- •9.2.6 Request Processing
- •9.2.7 Request Error
- •9.3 USB Device Requests
- •9.3.1 bmRequestType
- •9.3.2 bRequest
- •9.3.3 wValue
- •9.3.4 wIndex
- •9.3.5 wLength
- •9.4 Standard Device Requests
- •9.4.1 Clear Feature
- •9.4.2 Get Configuration
- •9.4.3 Get Descriptor
- •9.4.4 Get Interface
- •9.4.5 Get Status
- •9.4.6 Set Address
- •9.4.7 Set Configuration
- •9.4.8 Set Descriptor
- •9.4.9 Set Feature
- •9.4.10 Set Interface
- •9.4.11 Synch Frame
- •9.5 Descriptors
- •9.6 Standard USB Descriptor Definitions
- •9.6.1 Device
- •9.6.2 Configuration
- •9.6.3 Interface
- •9.6.4 Endpoint
- •9.6.5 String
- •9.7 Device Class Definitions
- •9.7.1 Descriptors
- •9.7.2 Interface(s) and Endpoint Usage
- •9.7.3 Requests
- •Chapter 10
- •10.1 Overview of the USB Host
- •10.1.1 Overview
- •10.1.2 Control Mechanisms
- •10.1.3 Data Flow
- •10.1.4 Collecting Status and Activity Statistics
- •10.1.5 Electrical Interface Considerations
- •10.2 Host Controller Requirements
- •10.2.1 State Handling
- •10.2.2 Serializer/Deserializer
- •10.2.3 Frame Generation
- •10.2.4 Data Processing
- •10.2.5 Protocol Engine
- •10.2.6 Transmission Error Handling
- •10.2.7 Remote Wakeup
- •10.2.8 Root Hub
- •10.2.9 Host System Interface
- •10.3 Overview of Software Mechanisms
- •10.3.1 Device Configuration
- •10.3.2 Resource Management
- •10.3.3 Data Transfers
- •10.3.4 Common Data Definitions
- •10.4 Host Controller Driver
- •10.5 Universal Serial Bus Driver
- •10.5.1 USBD Overview
- •10.5.2 USBD Command Mechanism Requirements
- •10.5.3 USBD Pipe Mechanisms
- •10.5.4 Managing the USB via the USBD Mechanisms
- •10.5.5 Passing USB Preboot Control to the Operating System
- •10.6 Operating System Environment Guides
- •Chapter 11
- •11.1 Overview
- •11.1.1 Hub Architecture
- •11.1.2 Hub Connectivity
- •11.2 Hub Frame Timer
- •11.2.1 Frame Timer Synchronization
- •11.2.2 EOF1 and EOF2 Timing Points
- •11.3 Host Behavior at End-of-Frame
- •11.3.1 Latest Host Packet
- •11.3.2 Packet Nullification
- •11.3.3 Transaction Completion Prediction
- •11.4 Internal Port
- •11.4.1 Inactive
- •11.4.2 Suspend Delay
- •11.4.3 Full Suspend (Fsus)
- •11.4.4 Generate Resume (GResume)
- •11.5 Downstream Ports
- •11.5.1 Downstream Port State Descriptions
- •11.6 Upstream Port
- •11.6.1 Receiver
- •11.6.2 Transmitter
- •11.7 Hub Repeater
- •11.7.1 Wait for Start of Packet from Upstream Port (WFSOPFU)
- •11.7.2 Wait for End of Packet from Upstream Port (WFEOPFU)
- •11.7.3 Wait for Start of Packet (WFSOP)
- •11.7.4 Wait for End of Packet (WFEOP)
- •11.8 Bus State Evaluation
- •11.8.1 Port Error
- •11.8.2 Speed Detection
- •11.8.3 Collision
- •11.9 Suspend and Resume
- •11.10 Hub Reset Behavior
- •11.10.1 Hub Receiving Reset on Upstream Port
- •11.11 Hub Port Power Control
- •11.11.1 Multiple Gangs
- •11.12 Hub I/O Buffer Requirements
- •11.12.1 Pull-up and Pull-down Resistors
- •11.12.2 Edge Rate Control
- •11.13 Hub Controller
- •11.13.1 Endpoint Organization
- •11.13.2 Hub Information Architecture and Operation
- •11.13.3 Port Change Information Processing
- •11.13.4 Hub and Port Status Change Bitmap
- •11.13.5 Over-current Reporting and Recovery
- •11.14 Hub Configuration
- •11.15 Descriptors
- •11.15.1 Standard Descriptors
- •11.15.2 Class-specific Descriptors
- •11.16 Requests
- •11.16.1 Standard Requests
- •11.16.2 Class-specific Requests
- •Index
Universal Serial Bus Specification Revision 1.1
The USB defines four transfer types:
Control Transfers: Bursty, non-periodic, host software-initiated request/response communication, typically used for command/status operations.
Isochronous Transfers: Periodic, continuous communication between host and device, typically used for time-relevant information. This transfer type also preserves the concept of time encapsulated in the data. This does not imply, however, that the delivery needs of such data is always time-critical.
Interrupt Transfers: Small-data, low-frequency, bounded-latency communication.
Bulk Transfers: Non-periodic, large-packet bursty communication, typically used for data that can use any available bandwidth and can also be delayed until bandwidth is available.
Each transfer type is described in detail in the following four major sections. The data for any IRP is carried by the data field of the data packet as described in Section 8.4.3. Chapter 8 also describes details of the protocol that are affected by use of each particular transfer type.
5.5 Control Transfers
Control transfers allow access to different parts of a device. Control transfers are intended to support configuration/command/status type communication flows between client software and its function. A control transfer is composed of a Setup bus transaction moving request information from host to function, zero or more Data transactions sending data in the direction indicated by the Setup transaction, and a Status transaction returning status information from function to host. The Status transaction returns “success” when the endpoint has successfully completed processing the requested operation. Section 8.5.2 describes the details of what packets, bus transactions, and transaction sequences are used to accomplish a control transfer. Chapter 9 describes the details of the defined USB command codes.
Each USB device is required to implement the Default Control Pipe as a message pipe. This pipe is used by the USB System Software. The Default Control Pipe provides access to the USB device’s configuration, status, and control information. A function can, but is not required to, provide endpoints for additional control pipes for its own implementation needs.
The USB device framework (refer to Chapter 9) defines standard, device class, or vendor-specific requests that can be used to manipulate a device’s state. Descriptors are also defined that can be used to contain different information on the device. Control transfers provide the transport mechanism to access device descriptors and make requests of a device to manipulate its behavior.
Control transfers are carried only through message pipes. Consequently, data flows using control transfers must adhere to USB data structure definitions as described in Section 5.5.1.
The USB system will make a “best effort” to support delivery of control transfers between the host and devices. A function and its client software cannot request specific bus access frequency or bandwidth for control transfers. The USB System Software may restrict the bus access and bandwidth that a device may desire for control transfers. These restrictions are defined in Section 5.5.3 and Section 5.5.4.
5.5.1 Control Transfer Data Format
The Setup packet has a USB-defined structure that accommodates the minimum set of commands required to enable communication between the host and a device. The structure definition allows vendor-specific extensions for device specific commands. The Data transactions following Setup have a USB-defined structure except when carrying vendor-specific information. The Status transaction also has a USB-defined structure. Specific control transfer Setup/Data definitions are described in Section 8.5.2 and Chapter 9.
36
Universal Serial Bus Specification Revision 1.1
5.5.2 Control Transfer Direction
Control transfers are supported via bi-directional communication flow over message pipes. As a consequence, when a control pipe is configured, it uses both the input and output endpoint with the specified endpoint number.
5.5.3 Control Transfer Packet Size Constraints
An endpoint for control transfers specifies the maximum data payload size that the endpoint can accept from or transmit to the bus. The USB defines the allowable maximum control data payload sizes for fullspeed devices to be either 8, 16, 32, or 64 bytes. Low-speed devices are limited to only an eight-byte maximum data payload size. This maximum applies to the data payloads of the Data packets following a Setup; i.e., the size specified is for the data field of the packet as defined in Chapter 8, not including other information that is required by the protocol. A Setup packet is always eight bytes. A control pipe (including the Default Control Pipe) always uses its wMaxPacketSize value for data payloads.
An endpoint reports in its configuration information the value for its maximum data payload size. The USB does not require that data payloads transmitted be exactly the maximum size; i.e., if a data payload is less than the maximum, it does not need to be padded to the maximum size.
All Host Controllers are required to have support for 8-, 16-, 32-, and 64-byte maximum data payload sizes for full-speed control endpoints and only eight-byte maximum data payload sizes for low-speed control endpoints. No Host Controller is required to support larger or smaller maximum data payload sizes.
In order to determine the maximum packet size for the Default Control Pipe, the USB System Software reads the device descriptor. The host will read the first eight bytes of the device descriptor. The device always responds with at least these initial bytes in a single packet. After the host reads the initial part of the device descriptor, it is guaranteed to have read this default pipe’s wMaxPacketSize field (byte 7 of the device descriptor). It will then allow the correct size for all subsequent transactions. For all other control endpoints, the maximum data payload size is known after configuration so that the USB System Software can ensure that no data payload will be sent to the endpoint that is larger than the supported size. The host will always use a maximum data payload size of at least eight bytes.
An endpoint must always transmit data payloads with a data field less than or equal to the endpoint’s wMaxPacketSize (refer to Chapter 9). When a control transfer involves more data than can fit in one data payload of the currently established maximum size, all data payloads are required to be maximum-sized except for the last data payload, which will contain the remaining data.
The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of the following:
Has transferred exactly the amount of data specified during the Setup stage
Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet.
When a Data stage is complete, the Host Controller advances to the Status stage instead of continuing on with another data transaction. If the Host Controller does not advance to the Status stage when the Data stage is complete, the endpoint halts the pipe as was outlined in Section 5.3.2. If a larger-than-expected data payload is received from the endpoint, the IRP for the control transfer will be aborted/retired.
The Data stage of a control transfer from the host to an endpoint is complete when all of the data has been transferred. If the endpoint receives a larger-than-expected data payload from the host, it halts the pipe.
37
Universal Serial Bus Specification Revision 1.1
5.5.4 Control Transfer Bus Access Constraints
Control transfers can be used by full-speed and low-speed USB devices.
An endpoint has no way to indicate a desired bus access frequency for a control pipe. The USB balances the bus access requirements of all control pipes and the specific IRPs that are pending to provide “best effort” delivery of data between client software and functions.
The USB requires that part of each frame be reserved to be available for use by control transfers as follows:
If the control transfers that are attempted (in an implementation-dependent fashion) consume less than 10% of the frame time, the remaining time can be used to support bulk transfers (refer to Section 5.8).
A control transfer that has been attempted and needs to be retried can be retried in the current or a future frame; i.e., it is not required to be retried in the same frame.
If there are more control transfers than reserved time, but there is additional frame time that is not being used for isochronous or interrupt transfers, a Host Controller may move additional control transfers as they are available.
If there are too many pending control transfers for the available frame time, control transfers are selected to be moved over the bus as appropriate.
If there are control transfers pending for multiple endpoints, control transfers for the different endpoints are selected according to a fair access policy that is Host Controller implementationdependent.
A transaction of a control transfer that is frequently being retried should not be expected to consume an unfair share of the bus time.
These requirements allow control transfers between host and devices to be regularly moved over the bus with “best effort.”
The rate of control transfers to a particular endpoint can be varied by the USB System Software at its discretion. An endpoint and its client software cannot assume a specific rate of service for control transfers. A control endpoint may see zero or more transfers in a single frame. Bus time made available to a software client and its endpoint can be changed as other devices are inserted into and removed from the system or also as control transfers are requested for other device endpoints.
The bus frequency and frame timing limit the maximum number of successful control transfers within a frame for any USB system to less than 29 full-speed eight-byte data payloads or less than four low-speed eight-byte data payloads. Table 5-1 lists information about different-sized full-speed control transfers and the maximum number of transfers possible in a frame. This table was generated assuming that there is one Data stage transaction and that the Data stage has a zero-length status phase. The table illustrates the possible power of two data payloads less than or equal to the allowable maximum data payload sizes. The table does not include the overhead associated with bit stuffing.
38
Universal Serial Bus Specification Revision 1.1
Table 5-1. Full-speed Control Transfer Limits
|
Protocol Overhead (45 bytes) |
(9 SYNC bytes, 9 PID bytes, 6 Endpoint + CRC bytes, 6 |
||||
|
|
|
CRC bytes, 8 Setup data bytes, and a 7-byte interpacket |
|||
|
|
|
delay (EOP, etc.)) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Data |
Max Bandwidth |
Frame |
Max |
Bytes |
Bytes/Frame |
|
Payload |
(bytes/second) |
Bandwidth |
Transfers |
Remaining |
Useful Data |
|
|
|
per |
|
|
|
|
|
|
Transfer |
|
|
|
|
|
|
|
|
|
|
|
1 |
32000 |
3% |
32 |
23 |
32 |
|
|
|
|
|
|
|
|
2 |
62000 |
3% |
31 |
43 |
62 |
|
|
|
|
|
|
|
|
4 |
120000 |
3% |
30 |
30 |
120 |
|
|
|
|
|
|
|
|
8 |
224000 |
4% |
28 |
16 |
224 |
|
|
|
|
|
|
|
|
16 |
384000 |
4% |
24 |
36 |
384 |
|
|
|
|
|
|
|
|
32 |
608000 |
5% |
19 |
37 |
608 |
|
|
|
|
|
|
|
|
64 |
832000 |
7% |
13 |
83 |
832 |
|
|
|
|
|
|
|
Max |
|
1500000 |
|
|
|
1500 |
|
|
|
|
|
|
|
The 10% frame reservation for non-periodic transfers means that in a system with bus time fully allocated, all full-speed control transfers in the system contend for a nominal three control transfers per frame. Because the USB system uses control transfers for configuration purposes in addition to whatever other control transfers other client software may be requesting, a given software client and its function should not expect to be able to make use of this full bandwidth for its own control purposes. Host Controllers are also free to determine how the individual bus transactions for specific control transfers are moved over the bus within and across frames. An endpoint could see all bus transactions for a control transfer within the same frame or spread across several noncontiguous frames. A Host Controller, for various implementation reasons, may not be able to provide the theoretical maximum number of control transfers per frame.
Both full-speed and low-speed control transfers contend for the same available frame time. Low-speed control transfers simply take longer to transfer. Table 5-2 lists information about different-sized low-speed packets and the maximum number of packets possible in a frame. The table does not include the overhead associated with bit stuffing. For both speeds, because a control transfer is composed of several packets, the packets can be spread over several frames to spread the bus time required across several frames.
39