Jan Axelson, USB Complete
Подождите немного. Документ загружается.
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