UM10503
All information provided in this document is subject to legal disclaimers.
© NXP B.V. 2012. All rights reserved.
User manual
Rev. 1.3 — 6 July 2012
567 of 1269
NXP Semiconductors
UM10503
Chapter 23: LPC43xx USB0 Host/Device/OTG controller
23.10.5.3.1
Data toggle reset
The DCD may reset the data toggle state bit and cause the data toggle sequence to reset
in the device controller by writing a ‘1’ to the data toggle reset bit in the ENDPTCTRLx
register. This should only be necessary when configuring/initializing an endpoint or
returning from a STALL condition.
23.10.5.3.2
Data toggle inhibit
Remark:
This feature is for test purposes only and should never be used during normal
device controller operation.
Setting the data toggle Inhibit bit active (‘1’) causes the device controller to ignore the data
toggle pattern that is normally sent and accept all incoming data packets regardless of the
data toggle state. In normal operation, the device controller checks the DATA0/DATA1 bit
against the data toggle to determine if the packet is valid. If 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 host controller from re-sending the same packet, the device controller will
respond to the error packet by acknowledging it with either an ACK or NYET response.
23.10.6 Operational model for packet transfers
All transactions on the USB bus are initiated by the host and in turn, the device must
respond to any request from the host within the turnaround time stated in the USB 2.0
Specification. At USB 1.1 Full or Low Speed rates, this turnaround time was significant
and the USB 1.1 device controllers were designed so that the device controller could
access main memory or interrupt a host protocol processor in order to respond to the USB
1.1 transaction. The architecture of the USB 2.0 device controller is different because the
same methods will not meet USB 2.0 High-speed turnaround time requirements by simply
increasing the clock rate.
A USB host will send requests to the device controller 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, then we can expect the host will send IN requests
to that endpoint. This device controller is designed in such a way that it can prepare
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 will be used
throughout the following documentation to describe the device controller operation so the
DCD can be designed properly to use priming. Further, note that the term “flushing” is
used to describe the action of clearing a packet that was queued for execution.
23.10.6.1 Priming transmit endpoints
Priming a transmit endpoint will cause 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 will be 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