Product manual

Spinpoint M9TU-USB 3.0 Product Manual REV 1.0
43
USB INTERFACE AND USB COMMANDS
6.3.3 Packet Format
This section shows packet formats for token, data, and handshake packets. Fields within a packet are displayed
in these figures in the order in which bits are shifted out onto the bus.
6.3.3.1 Token Packet
Figure 6-18 shows the field formats for a token packet. A token consists of 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 uniquely identify the endpoint
that will receive the subsequent Data packet. For IN transactions, these fields uniquely identify which endpoint
should transmit a Data packet. For PING transactions, these fields uniquely identify which endpoint will respond
with a handshake packet. Only the host can issue token packets. An IN
PID defines 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 packets have a five-bit CRC that covers the address
and endpoint fields as shown above. The CRC does not cover
the PID, which has its own check field. Token and SOF
packets are delimited by an EOP after three bytes of packet
field data. If a packet decodes as an otherwise valid token or
SOF but does not terminate with an EOP after three bytes, it
must be considered invalid and ignored by the receiver.
6.3.3.2 Data Packet
A data packet consists of a PID, a data field containing zero
or more bytes of data, and a CRC as shown in Figure 6-19.
There are four types of data packets, identified by differing
PIDs: DATA0, DATA1, DATA2 and MDATA. Two data
packet PIDs (DATA0 and DATA1) are defined to support
data toggle synchronization. All four data PIDs are used in
data PID sequencing for high bandwidth high-speed
isochronous endpoints. Three data PIDs (MDATA, DATA0,
DATA1) are used in split transactions.
Data must always be sent in integral numbers of bytes. The data CRC is computed over only the data field in
the packet and does not include the
PID, which has its own check field. The maximum data payload size allowed
for low-speed devices is 8 bytes. The maximum data payload size for full-speed devices is 1023. The maximum
data payload size for high-speed devices is 1024 bytes.
6.3.3.3 Handshake Packet
Handshake packets, as shown in Figure 6-20, consist of only a PID. Handshake packets are used to report the
status of a data transaction and can return values indicating successful reception of data, command acceptance or
rejection, flow control, and halt conditions. Only transaction types that support flow control can return
handshakes. 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 must be
considered
invalid and ignored by the receiver.
There are four types of handshake packets and one special handshake packet:
ACK indicates that the data packet was received without bit stuff or CRC errors
over the data field and that the data PID was received correctly. ACK may be
issued either when sequence bits match and the receiver can accept data or when
sequence bits mismatch and the sender and receiver must resynchronize to each
other. An ACK handshake is applicable only in transactions in which data has been
transmitted and where a handshake is expected. ACK can be returned by the host
for IN transactions and by a function for OUT, SETUP, or PING transactions.
NAK indicates that a function was unable to accept data from the host (OUT) or that a function has no data to
transmit to the host (IN). NAK can only be returned by functions in the data phase of IN transactions or the
handshake phase of OUT or PING transactions. The host can never issue NAK. NAK is used for flow control
purposes to indicate that a function is temporarily unable to transmit or receive data, but will eventually be able to
do so without need of host intervention.
STALL is returned by a function in response to an IN token or after the data phase of an OUT or in response to a
PING transaction. STALL indicates that a function is unable to transmit or receive data, or that a control pipe
request is not supported. The state of a function after returning a STALL (for any endpoint except the default
endpoint) is undefined. The host is not permitted to return a STALL under any condition.
Figure 6-19 : Data Packet Format
Figure 6-18 : Token Format
Figure 6-20 : Handshake
Format