USB2.0 Spec simple review

1 Basic knowledge

Bandwidth	The amount of data transmitted per unit of time, typically bits per second (b/s) or bytes per second (B/s).
EOF	End-of-(micro)Frame
EOP	End-of-Packet
SOF	Start-of-(micro)Frame - The first transaction in each (micro)frame
SOP	Start-of-Packet
Pipe	A logical abstraction representing the association between an endpoint on a device and software on the host
Microframe	A 125 microsecond time base established on high-speed buses.
Phase	A token, data, or handshake packet. A transaction has three phases.

2 Architecture Overview

2.1 Electrical

There are three data rates:

• The USB high-speed signaling bit rate is 480 Mb/s.

• The USB full-speed signaling bit rate is 12 Mb/s.

• A limited capability low-speed signaling mode is also defined at 1.5 Mb/s.

• The clock is transmitted, encoded along with the differential data.

• The clock encoding scheme is NRZI with bit stuffing to ensure adequate transitions.

• In NRZI encoding, a “1” is represented by no change in level and a “0” is represented by a change in level.

• self-powered or bus-powered devices

2.2 Bus Protocol

• The USB is a polled bus. The Host Controller initiates all data transfers.
• The USB data transfer model between a source or destination on the host and an endpoint on a device is referred to as a pipe.
• One message pipe, the Default Control Pipe, always exists once a device is powered, in order to provide access to the device’s configuration, status, and control information.

2.3 Error Behavior

• The protocol includes separate CRCs for control and data fields of each packet.
• When data integrity is required, such as with lossless data devices, an error recovery procedure may be invoked in hardware or software.
• The protocol allows for error handling in hardware or software. Hardware error handling includes reporting and retry of failed transfers.

2.4 System Configuration

• USB data transfers take place between host software and a particular endpoint on a USB device.
• Such associations between the host software and a USB device endpoint are called pipes.
• The USB architecture comprehends four basic types of data transfers: Control Transfers, Bulk Transfers, Interrupt Transfers, Isochronous Transfers
  

3 USB Data Flow Model

• USB Physical Device: A piece of hardware on the end of a USB cable that performs some useful end user function.
• Client Software: Software that executes on the host, corresponding to a USB device. This client
  software is typically supplied with the operating system or provided along with the USB device.
• USB System Software: Software that supports the USB in a particular operating system. The USB
  System Software is typically supplied with the operating system, independently of particular USB
  devices or client software.
• USB Host Controller (Host Side Bus Interface): The hardware and software that allows USB devices to be attached to a host.

3.1 Device Endpoints

• Each USB logical device is composed of a collection of independent endpoints.
• All USB devices are required to implement a default control method that uses both the input and output endpoints with endpoint number zero.

3.2 Pipes

• A USB pipe is an association between an endpoint on a device and software on the host.
• Pipes represent the ability to move data between software on the host via a memory buffer and an endpoint on a device.
• There are two mutually exclusive pipe communication modes:
• • Stream: Data moving through a pipe has no USB-defined structure, Stream pipes support bulk, isochronous, and interrupt transfer types
• • Message: Data moving through a pipe has some USB-defined structure, Message pipes support the control transfer type
• The Default Control Pipe is used by the USB System Software to determine device identification and configuration requirements and to configure the device
• A software client normally requests data transfers via I/O Request Packets (IRPs) to a pipe and then either waits or is notified when they are completed.

3.3 Frames and Microframes

• USB establishes a 1 millisecond time base called a frame on a full-/low-speed bus and a 125 μs time base called a microframe on a high-speed bus.
• A (micro)frame can contain several transactions.

3.4 Control Transfers

• Used to configure a device at attach time and can be used for other device-specific purposes, including control of other pipes on the device.
• 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 maximum control transfer data payload sizes for full-speed devices is
  8, 16, 32, or 64 bytes; for high-speed devices, it is 64 bytes and for low-speed devices, it is 8 bytes.
• A Setup packet is always 8 bytes.

3.5 Bulk Transfers

• Generated or consumed in relatively large and bursty quantities and have wide dynamic latitude in transmission constraints.Bulk data typically consists of larger amounts of data.
• The USB defines the allowable maximum bulk data payload sizes to be only 8, 16, 32, or 64 bytes for full-speed endpoints and 512 bytes for high-speed endpoints.

3.6 Interrupt Transfers

• Used for timely but reliable delivery of data, for example, characters or coordinates with human-perceptible echo or feedback response characteristics.
• Interrupt data typically consists of event notification, characters, or coordinates that are organized as one or more bytes.
• The maximum allowable interrupt data payload size is 64 bytes or less for full-speed. High-speed endpoints are allowed maximum data payload sizes up to 1024 bytes.

3.7 Isochronous Transfers

• Occupy a prenegotiated amount of USB bandwidth with a prenegotiated delivery latency. (Also called streaming real time transfers).
• Any error in electrical transmission is not corrected by hardware mechanisms such as retries.
• The USB limits the maximum data payload size to 1,023 bytes for each full-speed isochronous endpoint. High-speed endpoints are allowed up to 1024-byte data payloads.

3.8 Split Transactions

• Host controllers and hubs support one additional transaction type called split transactions.
• This transaction type allows full- and low-speed devices to be attached to hubs operating at high-speed.
• These transactions involve only host controllers and hubs and are not visible to devices.

3.9 Bus Access for Transfers

• Transfer Management: The entities and the objects that support communication flow over the USB
• Transaction Tracking: The USB mechanisms that are used to track transactions as they move through the USB system
• Bus Time: The time it takes to move a packet of information over the bus
• Device/Software Buffer Size: The space required to support a bus transaction
• Bus Bandwidth Reclamation: Conditions where bandwidth that was allocated to other transfers but was not used and can now be possibly reused by control and bulk transfers

3.10 Transaction Packet Sequences

• The packets that comprise a transaction varies depending on the endpoint type. There are four endpoint types: bulk, control, interrupt, and isochronous.

3.10.1 Bulk transaction

• Bulk transactions use a three-phase transaction consisting of token, data, and handshake packets.
  

3.10.2 Control transfer

• Control transfers minimally have three transaction stages: Setup , Data(optional), and Status.
• SETUP stage
• • During the Setup stage, a SETUP transaction is used to transmit information to the control endpoint of a function.
    
• Data and status stage
• • The Data stage, a control transfer consists of one or more IN or OUT transactions and follows the same protocol rules as bulk transfers.
• • The Status stage of a control transfer is the last transaction in the sequence. The status stage transactions follow the same protocol sequence as bulk transactions.
    

3.10.3 Interrupt Transaction

• Interrupt transactions may consist of IN or OUT transfers.
  

3.10.4 IsochronousTransaction

• Isochronous transactions have a token and data phase, but no handshake phase.
  

3.11 Data Toggle Synchronization and Retry

• Synchronization is achieved via use of the DATA0 and DATA1 PIDs and separate data toggle sequence bits for the data transmitter and receiver.
• Receiver sequence bits toggle only when the receiver is able to accept data and receives an error-free data packet with the correct data PID.
• Transmitter sequence bits toggle only when the data transmitter receives a valid ACK handshake.

3.11.1 Data Corrupted or Not Accepted

• If data cannot be accepted or the received data packet is corrupted, the receiver will issue a NAK or STALL handshake, or timeout, depending on the circumstances, and the receiver will not toggle its sequence bit.
• The transaction will then be retried and, if successful, will cause both transmitter and receiver sequence bits to toggle.

3.11.2 Corrupted ACK Handshake

• A lost or corrupted ACK handshake can lead to a temporary loss of synchronization between transmitter and receiver.
  
• The receiver has received good data, but the transmitter does not know whether it has successfully sent data.
• On the next transaction, the transmitter will resend the previous data using the previous DATA0 PID.
• The receiver’s sequence bit and the data PID will not match, so the receiver knows that it has previously accepted this data. Consequently, it discards the incoming data packet and does not toggle its sequence bit.
• The receiver then issues ACK, which causes the transmitter to regard the retried transaction as successful. Receipt of ACK causes the transmitter to toggle its sequence bit.

3.12 Error Detection and Recovery

3.12.1 Packet Error

• With the exception of the SOF token, any packet that is received corrupted causes the receiver to ignore it and discard any data or other field information that came with the packet.
  

3.12.2 Bus Turn-around Timing

• The host and USB function need to keep track of how much time has elapsed from when the transmitter completes sending a packet until it begins to receive a response packet.
• The device bus turn-around time is defined by the worst case round trip delay plus the maximum device response delay .
• If a response is not received within this worst case timeout, then the transmitter considers that the packet transmission has failed.
• Timeout is used and interpreted as a transaction error condition for many transfer types.

3.12.3 False EOPs(TODO)

3.12.4 Babble and Loss of Activity Recovery(TODO)

4 USB Device framework

4.1 Bus Enumeration

When a USB device is attached to or removed from the USB, the host uses a process known as bus
enumeration to identify and manage the device state changes necessary. When a USB device is attached to a powered port, the following actions are taken:

1. The hub to which the USB device is now attached informs the host of the event via a reply on its status change pipe (refer to Section 11.12.3 for more information). At this point, the USB device is in the Powered state and the port to which it is attached is disabled.
2. The host determines the exact nature of the change by querying the hub.
3. Now that the host knows the port to which the new device has been attached, the host then waits for at least 100 ms to allow completion of an insertion process and for power at the device to become stable. The host then issues a port enable and reset command to that port. Refer to Section 7.1.7.5 for sequence of events and timings of connection through device reset.
4. The hub performs the required reset processing for that port (see Section 11.5.1.5). When the reset signal is released, the port has been enabled. The USB device is now in the Default state and can draw no more than 100 mA from VBUS. All of its registers and state have been reset and it answers to the default address.
5. The host assigns a unique address to the USB device, moving the device to the Address state.
6. Before the USB device receives a unique address, its Default Control Pipe is still accessible via the default address. The host reads the device descriptor to determine what actual maximum data payload size this USB device’s default pipe can use.
7. The host reads the configuration information from the device by reading each configuration zero to n- 1, where n is the number of configurations. This process may take several milliseconds to complete.
8. Based on the configuration information and how the USB device will be used, the host assigns a
   configuration value to the device. The device is now in the Configured state and all of the endpoints in this configuration have taken on their described characteristics. The USB device may now draw the amount of VBUS power described in its descriptor for the selected configuration. From the device’s point of view, it is now ready for use.

• When the USB device is removed, the hub again sends a notification to the host. Detaching a device disables the port to which it had been attached. Upon receiving the detach notification, the host will update its local topological information.

4.2 Standard USB Descriptor

• A device descriptor describes general information about a USB device. It includes information that applies globally to the device and all of the device’s configurations. A USB device has only one device descriptor.
• The configuration descriptor describes information about a specific device configuration. Each configuration has one or more interfaces
  and each interface has zero or more endpoints.
• The interface descriptor describes a specific interface within a configuration.
• An interface is a related set of endpoints that present a single feature or function of the device to the host.
• The endpoint descriptor contains the information required by the host to determine the bandwidth requirements of each endpoint.
• String descriptors are optional.

5 USB Host

5.1 overview

• The USB bus interface handles interactions for the electrical and protocol layers.

• The USB System uses the Host Controller to manage data transfers between the host and USB devices. it has three basic components, Host Controller Driver, USB Driver and Host Software.

• • The Host Controller Driver (HCD) exists to more easily map the various Host Controller implementations into the USB System,such that a client can interact with its device without knowing to which Host Controller the device is connected.
• • The USB Driver (USBD) provides the basic USB Driver Interface (USBDI) for clients to USB devices. The interface between the HCD and the USBD is known as the Host Controller Driver Interface (HCDI).
• • The client layer describes all the software entities that are responsible for directly interacting with USB devices.

• All hubs report internal status changes and their port change status via the status change pipe

• The host layers provide the following capabilities:
  • Detecting the attachment and removal of USB devices
  • Managing USB standard control flow between the host and USB devices
  • Managing data flow between the host and USB devices
  • Collecting status and activity statistics
  • Controlling the electrical interface between the Host Controller and USB devices, including the
  provision of a limited amount of power.

5.1 Data Flow

• The Host Controller is responsible for transferring streams of data between the host and USB devices.
  The USB supports four basic types of data transfers:
  • Control transfers
  • Isochronous transfers
  • Interrupt transfers
  • Bulk transfers

• Each device presents one or more interfaces that a client may use to communicate with the device.

• Each interface is composed of zero or more pipes that individually transfer data between the client and a particular endpoint on the device.

5.2 Host Controller requirements

5.2.1 State Handling

• As a component of the host, the Host Controller reports and manages its states.
• The root hub presents to the hub driver the same standard states as other USB devices.
• USB devices request a wakeup through the use of resume signaling . The Host Controller must notify the rest of the host of a resume event.

5.2.2 Serializer/Deserializer

5.2.3 Frame and Microframe Generation

• It is the Host Controller’s responsibility to partition USB time into quantities called “frames” when
  operating with full-speed devices, and “microframes” when operating with high-speed devices.
• Frames and microframes are created by the Host Controller through issuing Start-of-Frame (SOF) tokens. The SOF token is the first transmission in the (micro)frame period.
• If the Host Controller enters a state where it is not providing power on the bus, it must not generate SOFs and may enter a power-reduced state.

5.2.4 Data Processing

5.2.5 Protocol Engine

5.2.6 Transmission Error Handling

• The Host Controller must be capable of detecting the following transmission error conditions
  • Timeout conditions after a host-transmitted token or packet.
  • Data errors resulting in missing or invalid transmissions
  • Protocol errors

5.2.7 Remote Wakeup

5.2.8 Root Hub

• The root hub provides the connection between the Host Controller and one or more USB ports.

5.2.9 Port Resets

Host System Interface

• The Host Controller provides a high-speed bus-mastering interface to and from main system memory.

5.3 Overview of Software Mechanisms

• The HCD provides an abstraction of the Host Controller and an abstraction of the Host Controller’s view of data transfer across the USB.
• The USBD provides an abstraction of the USB device and of the data transfers between the client of the USBD and the function on the USB device.

5.3.1 Device Configuration

• The USB System assumes a specialized client of the USBD, called a hub driver, that acts as a
  clearinghouse for the addition and removal of devices from a particular hub.
• Once the hub driver receives such notifications, it will employ additional host software and other USBD clients, in an operating system specific manner, to recognize and configure the device.
• • When a device is attached, the hub driver receives a notification from the hub detecting the change.
• • The hub driver, using the information provided by the hub, requests a device identifier from the USBD.
• • The USBD in turn sets up the default pipe for that device and returns a device identifier to the hub driver.

5.3.1.1 Device and USB configuration(TODO)

• The software responsible for configuration can include the following:
  • The hub driver
  • Other host software
  • A device driver
• The configuring software first reads the device descriptor, then requests the description for each possible configuration. It may use the information provided to load a particular client, such as a device driver, which initially interacts with the device.
• Setting the device configuration sets up all of the endpoints on the device and returns a collection of interfaces to be used for data transfer by USBD clients. Each interface is a collection of pipes owned by a single client.

5.3.2 Resource Management

• Whenever a pipe is setup by the USBD for a given endpoint, the USB System must determine if it can support the pipe.
• • bandwidth check for that endpoint’s transfers. two stages to check for available bandwidth. First the maximum execution time for a transaction is calculated. Then the (micro)frame schedule is consulted to determine if the indicated transaction will fit.

5.3.3 Data Transfers

• The basis for all client-function communication is the interface: a bundle of related pipes associated with a particular USB device.

5.4 Universal Serial Bus Driver(TODO)

5.4.1 USBD Pipe Mechanisms(TODO)

5.4.2 Managing the USB via the USBD Mechanisms(TODO)

6 Hub Specification

6.1 overview

• Hubs provide the electrical interface between USB devices and the host.hubs must support:
  • Connectivity behavior
  • Power management
  • Device connect/disconnect detection
  • Bus fault detection and recovery
  • High-, full-, and low-speed device support

• A hub consists of three components: the Hub Repeater, the Hub Controller, and the Transaction Translator.

• • The Hub Repeater is responsible for managing connectivity between upstream and downstream facing ports which are operating at the same speed.
• • The Hub Controller provides status and control and permits host access to the hub.
• • The Transaction Translator takes high-speed split transactions and translates them to full-/low-speed transactions when the hub is operating at high-speed and has full-/low-speed devices attached.

6.2 Hub Controller

6.2.1 Endpoint Organization

• The Hub Class defines one additional endpoint beyond Default Control Pipe, which is required for all hubs: the Status Change endpoint.
• The host system receives port and hub status change notifications through the Status Change endpoint.
• The Status Change endpoint is an interrupt endpoint.
• When a status change bit is set, the hub responds with data, indicating the entity (hub or port) with a change bit set.
• When a hub detects a change on a port or when the hub changes its own state, the Status Change endpoint transfers data to the host.
• While a change bit is set, the hub continues to report a status change when polled until all change
  bits have been cleared by the USB System Software.
• The USB System Software uses the interrupt pipe associated with the Status Change endpoint to detect changes in hub and port status.
• The Hub and Port Status Change Bitmap, indicates whether the hub or a port has experienced a status change.

6.2 Hub Configuration

• Hubs are configured through the standard USB device configuration commands. Configuring a hub enables the Status Change endpoint