USB Complete fourth- P8 docx

If the host sends data when the device is too busy to accept data, the endpoint returns NAK in the handshake packet.. At low and full speeds, when the host wants to send data in a contro

A USB 2.0 hub communicates with a USB 2.0 host at high speed unless a USB 1.x hub is between the host and hub When a low- or full-speed device is attached to a USB 2.0 hub, the hub converts between speeds as needed But speed conversion isn’t all a hub does to manage multiple speeds High speed is 40× faster than full speed and 320× faster than low speed It doesn’t make sense for the entire bus to wait while a hub exchanges low- or full-speed data with a device

The solution is split transactions A USB 2.0 host uses split transactions when communicating with a low- or full-speed device on a high-speed bus What would be a single transaction at low or full speed usually requires two types of split transactions: one or more start-split transactions to send information to the device and one or more complete-split transactions to receive information from the device The exception is isochronous OUT transactions, which don’t use complete-split transactions because the device has nothing to send

Split transactions require more transactions to complete a transfer but make better use of bus time because they minimize the time spent waiting for a

low-or full-speed device to transfer data The components responsible flow-or perflow-orm- perform-ing split transactions are the USB 2.0 host controller and a USB 2.0 hub that has an upstream connection to a high-speed bus segment and a downstream connection to a low/full-speed bus segment The transactions at the device are identical whether the host is using split transactions or not At the host, device drivers and application software don’t have to know or care whether the host is using split transactions because the protocol is handled at a lower level Chapter

15 has more about how the host and hubs manage split transactions

'PUWTKPI5WEEGUUHWN6TCPUHGTU

USB 2.0 transfers use status and control codes and error-checking to help ensure that data gets to its destination as quickly as possible and without errors

5VCVWUCPF%QPVTQN

The USB 2.0 specification defines handshake codes that indicate acceptance of received data, support or non-support of a control request, flow-control condi-tions, and an endpoint’s HALT state

A code indicates the success or failure of all transactions except those in isochro-nous transfers In addition, in control transfers, the Status stage reports the suc-cess or failure of an entire transfer

The handshake codes travel in the handshake or data packet of a transaction The defined status codes are ACK, NAK, STALL, NYET, and ERR The absence of an expected handshake code indicates an error In all cases, the expected receiver of the handshake uses the information to help decide what to

do next Table 2-4 shows the status indicators and where they transmit in each transaction type

#%-ACK (acknowledge) indicates that a host or device has received data without error Devices must return ACK in the handshake packets of Setup transactions

if the token and data packets were received without error Devices may also return ACK in the handshake packets of OUT transactions The host returns ACK in the handshake packets of IN transactions if the token and data packets were received without error

0#-NAK (negative acknowledge) means the device is busy or has no data to return

If the host sends data when the device is too busy to accept data, the endpoint returns NAK in the handshake packet If the host requests data when the device has nothing to send, the endpoint returns NAK in the data packet In either case, NAK indicates a temporary condition, and the host normally retries later

up to a driver-defined limit

Hosts never send NAK Isochronous transactions don’t use NAK because they have no handshake packet for returning a NAK If a device or the host doesn’t receive transmitted isochronous data, it’s lost

56#

The STALL handshake can mean an unsupported control request, control request failed, or endpoint failed

On receiving an unsupported control-transfer request, the device returns STALL in the Data or Status stage The device also returns STALL if the device supports the request but for some reason can’t take the requested action For example, if the host sends a Set Configuration request to set the device configu-ration to 2, and the device supports only configuconfigu-ration 1, the device returns

STALL To clear this type of stall, the host sends another Setup packet to begin

a new control transfer The USB 2.0 specification calls this type of stall a proto-col stall

Another use of STALL is a response when the endpoint’s Halt feature is set, which means that the endpoint is unable to send or receive data at all The spec-ification calls this type of stall a functional stall

Bulk and interrupt endpoints must support the functional stall USB 2.0 con-trol endpoints may support the functional stall but have little reason to do so A control endpoint in a functional stall must continue to respond normally to other requests that monitor and control the stall condition An endpoint that is capable of responding to these requests is capable of communicating and thus shouldn’t be stalled Isochronous transactions don’t use STALL because they have no handshake packet for returning the STALL SuperSpeed control end-points can’t use the functional STALL

On receiving a functional STALL, the host drops all pending requests to the device and doesn’t resume communications until the host has sent a successful control request to clear the Halt feature on the device Hosts never send STALL

0;'6

Only high-speed devices send NYET (not yet) High-speed bulk and control

transfers support a protocol that enables the host to find out before sending

Table 2-4: The location, source, and contents of the handshake code depend on the type of transaction.

6TCPUCEVKQP

6[RGQT2+0)

3WGT[

NYET (high speed only), ERR (from hub

in complete split)

ERR (from hub in complete split)

PING

(high speed only)

no data packet

data if a device is ready to receive the data At low and full speeds, when the host wants to send data in a control, bulk, or interrupt transfer, the host sends the token and data packets and receives a reply from the device in the transac-tion’s handshake packet If not ready for the data, the device returns NAK and the host retries later Retrying can waste a lot of bus time if the data packets are large and the device is often not ready

High-speed bulk and control transfers with multiple data packets have a better way After receiving a data packet, a device endpoint can return a NYET hand-shake, which says the endpoint accepted the data but is not yet ready to receive another data packet When the host thinks the device might be ready, the host can send a PING token packet, and the endpoint returns either an ACK to indicate the device is ready for the next data packet or NAK or STALL if the device isn’t ready Sending a PING is more efficient than sending the entire data packet only to find out the device wasn’t ready and having to resend later Even after responding to a PING or OUT with ACK, an endpoint is allowed to return NAK on receiving the data packet that follows but should do so rarely The host then tries again with another PING The use of PING by the host is optional

A USB 2.0 hub may return NYET in a complete-split transaction Hosts and low- and full-speed devices never send NYET

'44

The ERR handshake is for use only by high-speed hubs in complete-split trans-actions ERR indicates the device didn’t return an expected handshake in the transaction the hub is completing with the host

0Q4GURQPUG

Another type of status indication occurs when the host or a device expects to receive a handshake but receives nothing This lack of response can occur if the receiver’s error-checking calculation detected an error On receiving no response, the sender knows it should retry After multiple failures, the sender can take other action

4GRQTVKPIVJG5VCVWUQH%QPVTQN6TCPUHGTU

In control transfers, the data and handshake packets in the Status stage indicate the status of the transfer Table 2-5 shows the status indicators for control trans-fers

For control write transfers, the device returns the status of the transfer in the data packet of the Status stage On accepting the request and receiving data in the Data stage (if present) without error, the device returns a ZLP Or the device may return NAK (busy) or STALL (failure) The host returns ACK to complete the transfer For an unsupported request, a device may return STALL in the Data stage to end the transfer

For control read transfers, on receiving data in the Data stage without error, the host sends a ZLP in the data packet of the Status stage The device responds with ACK (transaction complete), NAK (busy), or STALL (failure) A host may begin the Status stage before the device has sent all of the requested data pack-ets, and if so, the device must abandon the Data stage and return a handshake code

'TTQT%JGEMKPI

The USB specifications define hardware requirements that ensure that errors due to line noise are rare Still, a noise glitch or unexpectedly disconnected cable could corrupt a transmission USB packets include error-checking bits that enable a receiver to identify just about any received data that doesn’t match what was sent For transfers that use multiple transactions, a data-toggle value keeps the transmitter and receiver synchronized to ensure no transactions are missed

'TTQTEJGEMKPI$KVU

Token, data, and SOF packets include bits for use in error-checking The bit values are calculated using the cyclic redundancy check (CRC) algorithm detailed in the USB 2.0 specification Hardware performs the calculations,

Table 2-5: The Status stage of a control transfer indicates the success or failure

of the transaction (A device may also return STALL in the Data stage.)

%QPVTQN6TCPUHGT

6[RG 5VCVWU5VCIG&CVC&KTGEVKQP &CVC2CEMGV *CPFUJCMG2CEMGV Write (Host sends data

to device or no Data

stage)

NAK (busy), or STALL (failed)

ACK

Read (Device sends

data to host)

NAK (busy), or STALL (failed)

which must be fast to enable the device to meet the specification’s timing requirements

The CRC is applied to the data to be checked The sender, whether host or device, performs the calculation and sends the result along with the data The receiver performs the identical calculation on the received data If the results match, the data has arrived without error and the receiver returns ACK If the results don’t match, the receiver sends no handshake The absence of the expected handshake tells the sender to retry Hosts typically try a total of three times On giving up, the host can inform the driver that requested the transfer The PID field in token packets uses a simpler form of error checking The lower four bits in the field are the PID, and the upper four bits are the comple-ment The receiver can check the integrity of the PID by complementing the upper four bits and ensuring that they match the PID If not, the packet is cor-rupted and the receiver ignores the contents

6JG&CVC6QIING

The data-toggle value enables detecting missed or duplicate data packets in con-trol, bulk, and interrupt transfers IN and OUT transactions have a data-toggle value in the data packet’s PID field DATA0 is a code of 0011, and DATA1 is

1011 In controller chips, a register bit often indicates the data-toggle state, so the data-toggle value is sometimes called the data-toggle bit Each endpoint maintains its own data toggle

Both the sender and receiver keep track of the data toggle Host controllers han-dle data toggles at a low level that is invisible to applications and device drivers Some device controller chips handle the data toggles completely in hardware, while others require some firmware control If you’re debugging a device where the correct data is transmitting on the bus but the receiver is ignoring or dis-carding the data, chances are good that the device isn’t sending or expecting the correct data-toggle value

When the host configures a device on power up or attachment, the host and device each set their data toggles to DATA0 for all except some high-speed iso-chronous endpoints On detecting an incoming data packet, the host or device compares the state of its data toggle with the received data toggle If the values match, the receiver toggles its value and returns an ACK handshake packet The ACK causes the sender to toggle its value for the next transaction

The next received packet in the transfer should contain a data toggle of DATA1, and again the receiver toggles its bit and returns ACK The data toggle

on each end continues to alternate in each transaction, except for control trans-fers as explained below

If the receiver is busy and returns NAK, or if the receiver detects corrupted data and returns no response, the sender doesn’t toggle its bit and instead tries again with the same data and data toggle

If a receiver returns ACK but for some reason the sender doesn’t see the ACK, the sender will think that the receiver didn’t get the data and will try again using the same data and data-toggle bit In this case, the receiver of the repeated data ignores the data, doesn’t toggle the data toggle, and returns ACK The ACK re-synchronizes the data toggles If the sender mistakenly sends two packets in a row with the same data-toggle value, on receiving the second packet, the receiver ignores the data, doesn’t toggle its value, and returns ACK

Control transfers always use DATA0 in the Setup stage, use DATA1 in the first transaction of the Data stage, toggle the value in any additional Data-stage transactions, and use DATA1 in the Status stage Bulk endpoints toggle the value in every transaction, resetting the data toggle only after completing a Set Configuration, Set Interface, or Clear Feature(ENDPOINT_HALT) request Interrupt endpoints can behave the same as bulk endpoints Or to simplify pro-cessing with the risk of losing some data, an interrupt IN endpoint can toggle its data toggle in each transaction without checking for the host’s ACK Full-speed isochronous transfers always use DATA0 Isochronous transfers can’t use the data toggle to correct errors because there is no packet for returning ACK or NAK and no time to resend missed data

&CVC2+&5GSWGPEKPI

Some high-speed isochronous transfers use DATA0, DATA1, and additional PIDs of DATA2 and MDATA This use of the DATA and MDATA PIDs is called data PID sequencing High-speed isochronous IN transfers with two or three transactions per microframe use DATA0, DATA1, and DATA2 encoding

to indicate a transaction’s position in the microframe:

0WODGTQH+0

6TCPUCEVKQPURGT

/KETQHTCOG

&CVC2+&

(KTUV

6TCPUCEVKQP 5GEQPF6TCPUCEVKQP 6JKTF6TCPUCEVKQP

High-speed isochronous OUT transfers that have two or three transactions per microframe use DATA0, DATA1, and MDATA encoding to indicate whether more data will follow in the microframe:

5WRGT5RGGF6TCPUCEVKQPU

Like USB 2.0, SuperSpeed buses carry data, addressing, and status and control information But SuperSpeed has a dedicated data path for each direction, more support for power conservation, and other enhancements for greater efficiency

To support these differences, SuperSpeed transactions use different packet for-mats and protocols

2CEMGV6[RGU

SuperSpeed communications use two packet types when transferring data:

A Transaction Packet (TP) carries status and control information

A Data Packet (DP) carries data and status and control information

Two additional packet types perform other functions:

An Isochronous Timestamp Packet (ITP) carries timing information that devices can use for synchronization The host multicasts an ITP following each bus-interval boundary to all links that aren’t in a low-power state The timestamp holds a count from zero to 3FFFh and rolls over on overflow

A Link Management Packet (LMP) travels only in the link between a device’s port and the hub port the device connects to The ports are called link partners LMPs help manage the link

SuperSpeed doesn’t use token packets because packet headers contain the token packet’s information Instead of data toggles, SuperSpeed uses 5-bit sequence numbers that roll over from 31 to zero

0WODGTQH176

6TCPUCEVKQPURGT

/KETQHTCOG

&CVC2+&

(KTUV

6TCPUCEVKQP 5GEQPF6TCPUCEVKQP 6JKTF6TCPUCEVKQP

Each SuperSpeed packet has a 14-byte header followed by a 2-byte Link Con-trol Word (Table 2-6) The first five bits in the header are a Type field that iden-tifies the packet as one of the four types above Every header also contains type-specific information and a 16-bit CRC The Link Control Word (Table 2-7) provides information used in managing the transmission

A Data Packet consists of a Data Packet Header (DPH) followed immediately

by a Data Packet Payload (DPP) The Data Packet Header (Table 2-8) consists

of the 14-byte packet header and a Link Control Word The Data Packet Pay-load contains the transaction’s data and a 4-byte CRC A Data Packet PayPay-load with less than the endpoint’s maximum packet size bytes is a short packet A Data Packet Payload consisting of just the CRC and no data is a zero-length Data Payload

The other three packet types are always 128 bytes In a Transaction Packet, the Subtype field indicates the transaction’s purpose (Table 2-9) All Transaction Packets have a device address that indicates the source or destination of the packet All Transaction Packets sent by the host contain a Route String that hubs use in routing the packet to its destination

6TCPUHGTTKPI&CVC

A SuperSpeed transaction has one or two phases that each contain a Data Packet or a Transaction Packet

In a non-isochronous IN transaction, the host sends an ACK Transaction Packet to request data, and the device returns a Data Packet or a NRDY or STALL Transaction Packet

In an isochronous IN transaction, the host sends an ACK Transaction Packet to request data, and the device returns a Data Packet

Table 2-6: Each SuperSpeed packet has Type value, a CRC, and a Link Control Word.

In a non-isochronous OUT transaction, the host sends a Data Packet and the device returns an ACK, NRDY, or STALL Transaction Packet

In an isochronous OUT transaction, the host sends a Data Packet

5GSWGPEG0WODGTU

Table 2-10 shows the contents of the ACK Transaction Packet In an IN trans-action, on receiving an ACK Transaction Packet with NumP = 1, the endpoint sends a Data Packet with the Data Packet Header containing the Sequence Number of the received ACK Transaction Packet Except for isochronous trans-actions, on receiving the Data Packet, the host acknowledges receiving the data

by incrementing the Sequence Number and sending another ACK Transaction Packet If NumP > 0, the ACK Transaction Packet also serves as a request for more data In other words, instead of requiring separate transactions to ACK received data and request more data, a single ACK Transaction Packet can per-form both functions

In an OUT transaction, the Data Packet from the host contains a Sequence Number The ACK Transaction Packet the device sends in response contains the Sequence Number of the next expected Data Packet and serves as an implicit acknowledgement of receiving the previous Data Packet

In a control transfer, the Setup transaction packet and the first Data Packet Header each use a Sequence Number of zero (Note that this differs from USB 2.0, where the Data Stage begins with DATA1.) For any additional Data Pack-ets, the Sequence Number increments, resetting to zero on rollover

Table 2-7: Each packet has a Link Control Word with information used in

managing the transmission.

Number

Valid values are 0–7 in continuous sequence.

6–8 Hub Depth Valid only if Deferred is set Identifies the hub that deferred

the packet.

10 Deferred Set to 1 if a hub can’t send a packet because the downstream

port is in a power-managed state.