Chapter 2 46 5RNKV6TCPUCEVKQPU 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 for 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. Inside USB Transfers 47 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 configuration 1, the device returns Chapter 2 48 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[ &CVC2CEMGV *CPFUJCMG2CEMGV 5QWTEG %QPVGPVU 5QWTEG %QPVGPVU Setup host data device ACK OUT host data device ACK, NAK, STALL, NYET (high speed only), ERR (from hub in complete split) IN device data, NAK, STALL, ERR (from hub in complete split) host ACK PING (high speed only) no data packet – device ACK, NAK, STALL Inside USB Transfers 49 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. Chapter 2 50 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) IN ZLP (success), NAK (busy), or STALL (failed) ACK Read (Device sends data to host) OUT ZLP ACK (success), NAK (busy), or STALL (failed) Inside USB Transfers 51 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 Chapter 2 52 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 5GEQPF 6TCPUCEVKQP 6JKTF 6TCPUCEVKQP 1DATA0–– 2DATA1DATA0– 3 DATA2 DATA1 DATA0 Inside USB Transfers 53 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 5GEQPF 6TCPUCEVKQP 6JKTF 6TCPUCEVKQP 1DATA0–– 2 MDATA DATA1 – 3 MDATA MDATA DATA2 Chapter 2 54 (QTOCV 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 Payload 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. $KVU .GPIVJDKVU 7UG 0–4 5 Type Packet header 5–95 91 Fields specific to the packet type 96–111 16 CRC 112–127 16 Link Control Word Inside USB Transfers 55 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. $KVU 0COG &GUETKRVKQP 0–2 Header Sequence Number Valid values are 0–7 in continuous sequence. 3–5 Reserved – 6–8 Hub Depth Valid only if Deferred is set. Identifies the hub that deferred the packet. 9 Delayed Set to 1 if a hub resends or delays sending a Header Packet. 10 Deferred Set to 1 if a hub can’t send a packet because the downstream port is in a power-managed state. 11–15 CRC Error checking bits . 5RNKV6TCPUCEVKQPU 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. ERR (from hub in complete split) IN device data, NAK, STALL, ERR (from hub in complete split) host ACK PING (high speed only) no data packet – device ACK, NAK, STALL Inside USB Transfers 49 data. 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