MPC8536E-ANDROID Freescale Semiconductor, MPC8536E-ANDROID Datasheet - Page 1463

• Manufacturer Part Number: MPC8536E-ANDROID
• Description: HARDWARE/SOFTWARE ANDROID OS
• Manufacturer: Freescale Semiconductor
• Series: PowerQUICC ™r
• Type: MPUr

Specifications of MPC8536E-ANDROID

• Contents: Board
• For Use With/related Products: MPC8536
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

DCD). To prevent the USB 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.
21.8.3.3
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 Universal Serial Bus Revision 2.0 Specification.
A USB host will send requests to the USB 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 2 (transmit direction) is configured as a bulk pipe, then we can expect the host will
send IN requests to that endpoint. This USB controller 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 will be
used throughout the following documentation to describe the USB controller operation so the DCD can be
architected properly use priming. Further, note that the term ‘flushing’ is used to describe the action of
clearing a packet that was queued for execution.
21.8.3.3.1
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 fetch the operating context needed to handle 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 is split into virtual channels so that 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 ENDPTSTATUS
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.
Since only the leading data is stored in the device controller FIFO, it is necessary for the device controller
to begin filling in behind leading data after the transaction starts. The FIFO must be sized to account for
the maximum latency that can be incurred by the system memory bus.
21.8.3.3.2
Priming receive endpoints is identical to priming of transmit endpoints from the point of view of the DCD.
At the device controller the major difference in the operational model is that there is no data movement of
the leading packet data simply because the data is to be received from the host.
Note as part of the architecture, the FIFO for the receive endpoints is not partitioned into multiple channels
like the transmit FIFO. Thus, the size of the RX FIFO does not scale with the number of endpoints.
Freescale Semiconductor
Device Operational Model For Packet Transfers
Priming Transmit Endpoints
Priming Receive Endpoints
MPC8536E PowerQUICC III Integrated Processor Reference Manual, Rev. 1
Universal Serial Bus Interfaces
21-129