USB Specification

Universal Serial Bus Specification Revision 2.0 protocol layer


8.1 Byte/Bit Ordering


First, bits are sent out onto the bus least-significant bit, followed by the next LSb, through to the most- significant bit last.



8.2 SYNC Field


Packets always begin with a synchronization field, which is a coded sequence that creates a

maximum edge transition density. A SYNC from an initial transmitter is eight bits in length for full/low-speed and 32 bits for high-speed. The last two bits in the SYNC field are a marker that is used to recognize the end of the SYNC field and the beginning of the PID.



8.3 Packet Field Formats


A description of the field formats for the token, data, and handshake packets. Packet bit definitions are displayed in unencoded data format. All packets have distinct Start-of-Packet and End-of-Packet delimiters.



8.3.1 Packet Identifier Field


Packet identifiers (PID) immediately follow the SYNC field of every USB packet. PIDs consist of a four-bit packet type field followed by a four-bit check field. The PID indicates the type of packet, the packet format and the type of error detection applied to the packet. The four-bit check field of the PID ensures reliable decoding of the PID so that the remainder of the packet is interpreted correctly. The PID check field is generated by performing a one’s complement of the packet type field. A PID error exists if the four PID check bits are not complements of their respective packet identifier bits. The host and all functions must perform a complete decoding of all received PID fields. Any PID received

with a failed check field or which decodes to a non-defined value is assumed to be corrupted and it, as well as the remainder of the packet, is ignored by the packet receiver. If a function receives an otherwise valid PID for a transaction type or direction that it does not support, the function must not respond.


PID Format:

PID Types:









8.3.2 Address Fields


Function endpoints are addressed using two fields: the function address field and the endpoint field. Address or endpoint aliasing is not permitted, and an error on either field must cause the token to be ignored. Accesses to non-initialized endpoints will also cause the token to be ignored. Address Field


The function address field specifies the function that is either the source or destination of a data packet, depending on the value of the token PID. Each ADDR value defines a single function. Upon reset and power-up, a function’s address defaults to a value of zero and must be programmed by the host during the enumeration process. Function address zero is reserved as the default address and is not be assigned to any other use.


ADDR Field: Endpoint Field


An additional four-bit endpoint field, allows addressing of functions in which more than one endpoint is required. Except for endpoint address zero, endpoint numbers are function-specific. The endpoint field is defined for IN, SETUP, and OUT tokens and the PING special token. All functions must support a control pipe at endpoint number zero. Low- speed devices support a maximum of three pipes per function: a control pipe at endpoint number zero plus two additional pipes. Full-speed and high-speed functions may support up to a maximum of 16 IN and OUT endpoints.


Endpoint Field:













8.3.3 Frame Number Field


Frame number field is an 11-bit field that is augmented by a host on a per-frame basis. The frame

number field rolls over upon reaching its maximum value of 7FFH and is sent only in SOF tokens at the beginning of each frame.



8.3.4 Data Field


Data fields may range from 0 to 1024 bytes and must be an integral number of bytes. Data bits within each byte are shifted out LSb first.


Data Field Format:









8.3.5 Cyclic Redundancy Checks


Cyclic redundancy checks are used to shield all non-PID fields in token and data packets. The PID is not included in the CRC check of a packet containing a CRC. All Cyclic Redundancy Checks are created over their respective fields in the transmitter before bit stuffing is performed. Similarly, Cyclic Redundancy Checks are decoded in the receiver after stuffed bits have been removed. Token and data packet Cyclic Redundancy Checks provide full coverage for all single- and double-bit errors. A failed Cyclic Redundancy Check indicates that one or more of the protected fields is corrupted and causes the receiver to disregard those fields. Token Cyclic Redundancy Checks


A five-bit CRC field is assigned to tokens and covers the ADDR and ENDP fields of IN, SETUP, and

OUT tokens or the time stamp field of an SOF token. The PING and SPLIT special tokens also include a five-bit CRC field. The binary bit pattern is 00101B. If all token bits arrive without error, the five-bit residual at the receiver will be 01100B. Data Cyclic Redundancy Checks


The data CRC is a 16-bit polynomial provided over the data field of a data packet. The binary bit pattern that represents this polynomial is 1000000000000101B. If all data and CRC bits arrive without error, the 16-bit residual will be 1000000000001101B.




8.4 Packet Formats


A discussion of packet formats for token, data, and handshake packets. Fields within a packet are shown in the order in which bits are shifted out onto the bus.



8.4.1 Token Packets


A token is a PID, specifying either IN, OUT, or SETUP packet type and ADDR and ENDP fields. The PING special token packet also has the same fields as a token packet. For OUT and SETUP transactions, the address and endpoint fields recognize the endpoint that will accept the subsequent Data packet. For IN transactions, these fields recognize which endpoint should transmit a Data packet. For PING transactions, these fields recognize which endpoint will acknowledge with a handshake packet. Only the host can distribute token packets. An IN PID characterizes a Data transaction from a function to the host. OUT and SETUP PIDs define Data transactions from the host to a function. A PING PID defines a handshake transaction from the function to the host.


Token Format:


8.4.2 Split Transaction Special Token Packets


USB characterizes a special token for split transactions. SPLIT is a 4 byte token packet compared to other normal 3 byte token packets. The split transaction token packet accommodates supplementary transaction types with extra transaction specific information. The split transaction token is used to back split transactions between the host controller transmitting with a hub performing at high speed with full/low-speed devices to some of its downstream facing ports. There are two split transactions defined that use the SPLIT special token: a start-split transaction (SSPLIT) and a complete-split transaction (CSPLIT). A field in the SPLIT special token displays the split transaction.






 Split Transactions


High-speed split transactions are utilized only between a host controller and a hub when the hub has full/low-speed devices binded to it. These transactions are used to start a full/low-speed

transaction through the hub and some full/low-speed device endpoint. The high-speed split transaction also permits the completion status of the full/low-speed transaction to be reclaimed from the hub. This permits the host controller to initiate full/low-speed transactions through high-speed transactions and then with other high-speed transactions without having to wait for the full/low-speed transaction to continue at the slower speed. A high-speed split transaction has two parts: start-split and complete-split. Split transactions are used between the host controller and a hub. No other high-speed or full/low-speed devices ever use split transactions.


Packets in a Start-split Transaction:



Packets in a Complete-split Transaction:
















Relationship Interrupt IN Transaction to High-speed Split Transaction:




Relationship of Interrupt OUT Transaction to High-speed Split OUT Transaction: Start-Split Transaction Token


The Hub ADDR field includes the USB device address of the hub supporting the specified full/low-speed device for the full/low-speed transaction. A SPLIT special token packet with the Start/Complete field set to zero indicates that this is a start-split transaction. The Port field includes the port number of the target hub for the full/low-speed transaction.


Start-split Token:


Port Field:



Isochronous OUT start-split transactions use payload continuation encodings to permit the hub to detect various error cases due to lack of receiving start-split transactions for an endpoint with a data payload that has multiple start-splits. If any of these transactions is not received by the hub, it will either ignore the full-speed transaction, or it will force an error for the corresponding full-speed transaction. Other error conditions can be detected by not receiving a start-split during a microframe.


Speed specification for this interrupt/control transaction:


  • 0 – Full Speed
  • 1 – Low Speed


For bulk IN/OUT and isochronous IN start-splits, the S field must be set to zero. For bulk/control IN/OUT, interrupt IN/OUT, and isochronous IN start-splits, the E field must be set to zero.




Isochronous OUT Payload Continuation Encoding:


Endpoint Type Values in Split Special Token:

















 Complete-Split Transaction Token


A SPLIT special token packet with the SC field set to one shows that it’s is a complete-split transaction . The U bit is reserved/unused and must be reset to zero(0B). The other fields of the complete-split token packet have the same definitions as for the start-split token packet.


Complete-split (CSPLIT) Transaction Token:



8.4.3 Start-of-Frame Packets


Start-of-Frame packets are distributed by the host at a nominal rate of once every 1.00 ms ±0.0005 ms for a full-speed bus and 125 μs ±0.0625 μs for a high-speed bus.


SOF Packet: USB Frames and Microframes


USB categories a full-speed 1 millisecond frame time indicated by the SOF packet each and every 1 millisecond period with certain jitter tolerances. It also categories high-speed microframes with a 125 microsecond frame time with related jitter tolerances. SOF packets are created every 1 millisecond for full-speed links. SOF packets are also created after the next seven 125 microsecond periods for high-speed links.



Relationship between Frames and Microframes:




8.4.4 Data Packets


A data packet includes a PID, a data field containing zero or more bytes of data, and a CRC. There are four types of data packets, categorized by differing PIDs: DATA0, DATA1, DATA2 and MDATA. Two data packet PIDs (DATA0 and DATA1) support data toggle synchronization. These four data PIDs are utilized in data PID sequencing for high bandwidth high-speed isochronous endpoints. Three data PIDs (MDATA, DATA0, DATA1) are used in split transactions.


Data Packet Format:






8.4.5 Handshake Packets


Handshake packets include only a PID. Handshake packets report the status of a data transaction and return values displaying successful reception of data, command acceptance or rejection, flow control, and halt conditions. Handshakes are always returned in the handshake phase of a transaction and may be returned, instead of data, in the data phase. Handshake packets are delimited by an EOP after one byte of packet field. If a packet decodes as an otherwise valid handshake but does not terminate with an EOP after one byte, it is considered invalid and disregarded by the receiver.


There are 4 types of Handshake Packets and 1 unique Handshake Packet:


  • ACK – Shows that the data packet was received without bit stuff or CRC errors over the data field and that the data PID was received.
  • NAK – Shows that a function was unable to accept data from the host or that a function has no

data to transmit to the host.

  • STALL – Shows that a function is unable to transmit or receive data, or that a control pipe request is not supported.
  • NYET – High-speed only handshake that is returned by a high- speed endpoint as part of the PING protocol or by a hub in response to a split-transaction.
  • ERR – High-speed only handshake that is returned to permit a high-speed hub to report an error on a full/low-speed bus.



8.4.6 Handshake Responses


Transmitting and receiving functions return handshakes based upon an order of precedence. If an error occurs during the transmission of the token to the function, the function will not respond with any packets until the next token is received and decoded.
 Function Response to IN Transactions

 Host Response to IN Transactions Function Response to an OUT Transaction Function Response to a SETUP Transaction


SETUP defines a special type of host-to-function data transaction that allows the host to start an

endpoint’s synchronization bits to those of the host. Upon receiving a SETUP token, a function must accept the data. A function may not respond to a SETUP token with either STALL or NAK, and the receiving function must accept the data packet that follows the SETUP token. If a non-control endpoint receives a SETUP token, it must ignore the transaction and return no response.











8.5 Transaction Packet Sequences


The packets that make up a transaction are altered depending on the endpoint type. A host controller and device each require different state machines to sequence each type of transaction.


There are four endpoint types:


  • bulk
  • control
  • interrupt
  • isochronous


Legend for State Machines:











State Machine Context Overview:



Host Controller Top Level Transaction State Machine Hierarchy Overview:


















Host Controller Non-split Transaction State Machine Hierarchy Overview:
























Device Transaction State Machine Hierarchy Overview:























Device Top Level State Machine:


Device_process_Trans State Machine:































Dev_do_OUT State Machine:

















Dev_do_IN State Machine:





















HC_Do_nonsplit State Machine:



8.5.1 NAK Limiting via Ping Flow Model


Full/low-speed devices have bulk/control endpoints that respond to OUT transactions with a NAK handshake. This handshake response shows that the endpoint did not clear the data because it did not have space for it. The host controller will retry the transaction when the endpoint has more space. But by the time the endpoint NAKs, most of the full/low-speed bus time for the transaction had been used. As a result, full/low-speed buses have poor utilization when there is a high frequency of NAK OUT transactions.


High-speed devices support NAK mechanisms for Bulk OUT and Control endpoints and transactions. Control endpoints support this protocol for an OUT transaction in the data and status stages. The control Setup stage must does not support the PING protocol. This permits the device to inform the host controller whether it has enough endpoint space for the next OUT transaction. If the device endpoint does not have space, the host controller delays a transaction attempt for this endpoint and initiates another transaction. This leads to improved bus utilization. The mechanism avoids using bus time to send data until the host controller knows that the endpoint has space for the data.


The host controller queries the high-speed device endpoint with a PING special token. The endpoint either responds to the PING with a NAK or an ACK handshake. A NAK handshake shows that the endpoint does not have space for a wMaxPacketSize data payload. The host controller retries the PING to query the endpoint again. A NAK response is not a reason for the host controller to retire a transfer request. If a device responds with a NAK in a frame, the host controller may choose to issue the next transaction in the next b Interval specified for the endpoint. However, the device must be prepared to receive PINGs as sequential transactions.


An ACK handshake shows the endpoint has space for a wMaxPacketSize data payload. The host

controller creates an OUT transaction with a DATA phase as the next transaction to the endpoint.

The host controller may creates other transactions to other devices or endpoints before the OUT/DATA transaction for this endpoint.


If the endpoint responds to the OUT/DATA transaction with an ACK handshake, this means the endpoint accepted the data successfully and has room for another wMaxPacketSize data payload. The host controller continues with OUT/DATA transactions as long as it has transactions to create.


If the endpoint instead responds to the OUT/DATA transaction with a NYET handshake, this means that the endpoint accepted the data but does not have room for another wMaxPacketSize data payload. The host controller returns to using a PING token until the endpoint indicates it has space.













Host High-speed Bulk OUT/Control Ping State Machine:








 NAK Responses to OUT/DATA During PING Protocol


The endpoint also responds to the OUT/DATA transaction with a NAK handshake. This means that the endpoint did not accept the data and does not have space for a wMaxPacketSize data payload. The host controller returns to using a PING token until the endpoint shows it has space. A NAK response is an unusual occurrence. A high-speed bulk/control endpoint specifies its maximum NAK rate in its endpoint descriptor. The endpoint is permitted to NAK at most one time each b Interval period. A NAK suggests that the endpoint responded to a previous OUT or PING with an inappropriate handshake, or that the endpoint transitioned into a state where it could not accept data temporarily. An endpoint uses a b Interval of zero to show that it never NAKs. An endpoint always accepts a PING from the host, even if it never NAKs.


Dev_HS_ping State Machine:














Device High-speed Bulk OUT/Control State Machine:










8.5.2 Bulk Transactions


Bulk transaction types are identified by the ability to guarantee error-free delivery of data between the host and a function by means of error detection and retry. Bulk transactions use a three-phase transaction consisting of token, data, and handshake packets. Under certain flow control and halt conditions, the data phase is replaced with a handshake resulting in a two-phase transaction in which no data is transferred. The PING and NYET packets are only used with devices operating at high-speed.


Bulk Transaction Format:























Bulk/Control/Interrupt OUT Transaction Host State Machine:
















Bulk/Control/Interrupt OUT Transaction Device State Machine:











Bulk/Control/Interrupt IN Transaction Host State Machine:
















Bulk/Control/Interrupt In Transaction Device State Machine:



Data packet synchronization is achieved through use of the data sequence toggle bits and the DATA0/DATA1 PIDs. A bulk endpoint’s toggle sequence is initialized to DATA0 when the endpoint experiences any configuration event . Data toggle on an endpoint is not initialized as the direct result of a short packet transfer or the retirement of an IRP.


Sequence bit and data PID usage for bulk reads and writes :






8.5.3 Control Transfers


Control transfers have at least two transaction stages: Setup and Status. A control transfer can also contain a Data stage between the Setup and Status stages. During the Setup stage, a SETUP

transaction transfers information to the control endpoint of a function. SETUP transactions are

similar in format to an OUT but use a SETUP rather than an OUT PID. A SETUP always uses a DATA0 PID for the data field of the SETUP transaction. The function receiving a SETUP accepts the SETUP data and responds with ACK; if the data is corrupted, discard the data and return no handshake.


Control SETUP Transaction:



























The Data stage of a control transfer consists of one or more IN or OUT transactions and abides by

the same protocol rules as bulk transfers. All the transactions in the Data stage are in the same direction. The amount of data to be sent during the data stage and its direction are specified during the Setup stage. If the amount of data exceeds the data packet size, the data is sent in multiple transactions that carry the maximum packet size. Any remaining data is sent as a residual in the last transaction.


The Status stage is the last transaction of a control transfer. The status stage transactions abide by the same protocol sequence as bulk transactions. Status stage for devices running at high-speed also includes the PING protocol. A Status stage is delineated by a change in direction of data flow from the previous stage and always uses a DATA1 PID. If the control sequence has no Data stage, then it consists of a Setup stage followed by a Status stage consisting of an IN transaction.


Control Read and Write Sequences:
 Reporting Status Results


The Status stage reports to the host the result of the previous Setup and Data stages of the transfer. Three possible results may be returned:


  • The command sequence completed successfully
  • The command sequence failed to complete
  • The function is still busy completing the command


Status Stage Responses:


Status reporting is in the function-to-host direction. Control write transfers return status information in the data phase of the Status stage transaction. Control read transfers return status information in the handshake phase of a Status stage transaction, after the host has issued a zero-length data packet during the previous data phase.
 Variable-length Data Stage


Control pipes have a variable-length data phases in which the host requests more data than is contained in the specified data structure. When all of the data structure is returned to the host, the function shows that the Data stage is ended by returning a packet that is shorter than the MaxPacketSize for the pipe. If the data structure is an exact multiple of wMaxPacketSize for the pipe, the function returns a zero-length packet to show the end of the Data stage. Error Handling on the Last Data Transaction


If the ACK handshake on an IN transaction is corrupted, the function and the host temporarily deviate on whether the transaction was successful. If the transaction is followed by another IN, the toggle retry mechanism will detect the mismatch and recover from the error. If the ACK was on the last IN of a Data stage, the toggle retry mechanism cannot be used and an alternative scheme will be used.

The host that successfully interpreted the data of the last IN will send ACK. Later, the host will distribute an OUT token to start the Status stage of the transfer. If the function did not get the ACK that ended the Data stage, the function will decipher the start of the Status stage as verification that the host successfully received the data. STALL Handshakes Returned by Control Pipes


Control pipes can return a STALL handshake due to function problems in control transfers. If the device is incapable of completing a command, it returns a STALL in the Data and/or Status stages of the control transfer. The protocol STALL does not show an error with the device. The protocol STALL condition lasts until the receipt of the next SETUP transaction, and the function will return STALL in response to any IN or OUT transaction on the pipe until the SETUP transaction is received. In general, protocol stall shows that the request or its parameters are not understood by the device and thus provides a mechanism for extending USB requests.



8.5.4 Interrupt Transactions


Interrupt transactions consist of IN or OUT transfers. Upon receipt of an IN token, a function may

return data, NAK, or STALL. If the endpoint has no new interrupt information to return, the function returns a NAK handshake during the data phase. If the Halt feature is set for the interrupt endpoint, the function will return a STALL handshake. If an interrupt is pending, the function returns the interrupt information as a data packet. The host, in response to receipt of the data packet, distributes either an ACK handshake if data was received error-free or returns no handshake if the data packet was received corrupted.









Interrupt Transaction Format:



8.5.5 Isochronous Transactions


Isochronous transactions have a token and data phase, but no handshake phase . The host distributes either an IN or an OUT token followed by the data phase in which the endpoint or the host transfers data. Isochronous transactions do not support a handshake phase or retry capability.


Isochronous Transaction Format:















Isochronous OUT Transaction Host State Machine:



Isochronous OUT Transaction Device State Machine:






















Isochronous IN Transaction Device State Machine:






















8.6 Data Toggle Synchronization and Retry


The USB supplies a mechanism to guarantee data sequence synchronization between data transmitter and receiver across various transactions. This mechanism supplies a means of guaranteeing that the handshake phase of a transaction was deciphered perfectly by both the transmitter and receiver. Synchronization is achieved through 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 accepts 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. The data transmitter and receiver must have their sequence bits synchronized at the start of a transaction. The synchronization mechanism used varies with the transaction type. Data toggle synchronization is not supported for isochronous transfers.



8.6.1 Initialization through a SETUP Token


Control transfers utilize the SETUP token for launching the host and function sequence bits. The function accepts the data and returns ACK. When the function accepts the transaction, it sets its sequence bit so that both the host’s and function’s sequence bits are equal to one at the end of the SETUP transaction.







SETUP Initialization:


























8.6.2 Successful Data Transactions


During each transaction, the receiver compares the transmitter sequence bit with its receiver sequence bit. If data is not accepted, the receiver issues NAK and the sequence bits of both the transmitter and receiver remain unchanged. If data can be accepted and the receiver’s sequence bit matches the PID sequence bit, then data is accepted and the sequence bit is toggled. Two-phase transactions in which there is no data packet leave the transmitter and receiver sequence bits unchanged.


Consecutive Transactions:













8.6.3 Data Corrupted or Not Accepted


If data is not accepted or the received data packet is corrupted, the receiver distributes a NAK, STALL handshake, or timeout depending on the situation, and the receiver does not toggle its sequence bit.



8.6.4 Corrupted ACK Handshake


The transmitter is the only agent that understands whether a transaction has been successfully completed, because it receives an ACK handshake. A corrupted ACK handshake leads to a temporary loss of synchronization between transmitter and receiver . Here the transmitter issues a valid data packet, which is successfully acquired by the receiver; however, the ACK handshake is corrupted.



8.6.5 Low-speed Transactions



8.7 Error Detection and Recovery


The USB allows end-to-end communication in the presence of errors on the physical signaling

layer. This includes the ability to detect the majority of possible errors and to balance from

errors on a transaction-type basis.








8.7.1 Packet Error Categories


The USB applies three error detection mechanisms: bit stuff violations, PID check bits, and CRCs. 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.



8.7.2 Bus Turn-around Timing


Neither the device nor the host will send a forewarning that a received packet had an error. This absence of positive acknowledgement is the indication that there was an error. As a consequence of this method of error reporting, the host and USB function track of how much time has elapsed from when the transmitter finishes sending a packet until it starts to receive a response packet. This is the bus turn-around time.


Bus Turn-around Timer Usage:



8.7.3 False EOPs


False EOPs are handled to guarantee that the packet currently in progress completes before a device attempts to transfer a new packet. If this occurred, it would aggregate a bus collision and have the ability to corrupt up to two consecutive transactions. Detection of false EOP depends upon the fact that a packet into which a false EOP has been inserted will appear as a truncated packet with a CRC failure.



8.7.4 Babble and Loss of Activity Recovery


LOA and babble have the potential to either deadlock the bus or delay the beginning of the next frame. Neither condition is acceptable, and both are prevented from occurring. As the USB component responsible for controlling connectivity, hubs are responsible for babble/LOA detection and recovery. All USB devices that fail to complete their transmission at the end of a frame are prevented from transmitting past a frame’s end by having the nearest hub disable the port to which the offending device is attached.

Leave a Reply

Your email address will not be published. Required fields are marked *