Freescale Semiconductor MCF54455 Reference Manual page 269

Universal Serial Bus Interface – On-The-Go Module
Data Toggle Inhibit
This feature is for test purposes only and must never be used during normal device controller operation.
Setting the data toggle inhibit bit causes the USB OTG module to ignore the data toggle pattern normally
sent and accepts all incoming data packets regardless of the data toggle state.
In normal operation, the USB OTG checks the DATA0/DATA1 bit against the data toggle to determine if
the packet is valid. If the data PID does not match the data toggle state bit maintained by the device
controller for that endpoint, the data toggle is considered not valid. If the data toggle is not valid, the device
controller assumes the packet was already received and discards the packet (not reporting it to the DCD).
To prevent the USB OTG from re-sending the same packet, the device controller responds to the error
packet by acknowledging it with an ACK or NYET response.
10.5.3.4 Packet Transfers
The host initiates all transactions on the USB bus and in turn, the device must respond to any request from
the host within the turnaround time stated in the USB 2.0 specification.
A USB host sends requests to the USB OTG in an order that can not be precisely predicted as a single
pipeline, so it is not possible to prepare a single packet for the device controller to execute. However, the
order of packet requests is predictable when the endpoint number and direction is considered. For example,
if endpoint 3 (transmit direction) is configured as a bulk pipe, expect the host to send IN requests to that
endpoint. This USB OTG module prepares packets for each endpoint/direction in anticipation of the host
request. The process of preparing the device controller to send or receive data in response to host initiated
transaction on the bus is referred to as priming the endpoint. This term appears throughout the
documentation to describe the USB OTG operation so the DCD is built properly. Further, the term flushing
describes the action of clearing a packet queued for execution.
10.5.3.4.1 Priming Transmit Endpoints
Priming a transmit endpoint causes the device controller to fetch the device transfer descriptor (dTD) for
the transaction pointed to by the device queue head (dQH). After the dTD is fetched, it is stored in the dQH
until the device controller completes the transfer described by the dTD. Storing the dTD in the dQH allows
the device controller to fetch the operating context needed to manage a request from the host without the
need to follow the linked list, starting at the dQH when the host request is received.
After the device has loaded the dTD, the leading data in the packet is stored in a FIFO in the device
controller. This FIFO splits into virtual channels so the leading data can be stored for any endpoint up to
the maximum number of endpoints configured at device synthesis time.
After a priming request is complete, an endpoint state of primed is indicated in the EPSR register. For a
primed transmit endpoint, the device controller can respond to an IN request from the host and meet the
stringent bus turnaround time of high-speed USB.
10-62 Freescale Semiconductor