LPC1837FET256,551 NXP Semiconductors, LPC1837FET256,551 Datasheet - Page 419

• Manufacturer Part Number: LPC1837FET256,551
• Description: Microcontrollers (MCU) 32BIT ARM CORTEX-M3 MCU 136KB SRAM
• Manufacturer: NXP Semiconductors
• Series: LPC18xxr

Specifications of LPC1837FET256,551

• Core: ARM Cortex M3
• Core Processor: ARM® Cortex-M3™
• Core Size: 32-Bit
• Speed: 150MHz
• Connectivity: CAN, EBI/EMI, Ethernet, I²C, Microwire, SD/MMC, SPI, SSI, SSP, UART/USART, USB OTG
• Peripherals: Brown-out Detect/Reset, DMA, I²S, Motor Control PWM, POR, PWM, WDT
• Number Of I /o: 80
• Program Memory Size: 1MB (1M x 8)
• Program Memory Type: FLASH
• Eeprom Size: -
• Ram Size: 136K x 8
• Voltage - Supply (vcc/vdd): 2 V ~ 3.6 V
• Data Converters: A/D 16x10b; D/A 1x10b
• Oscillator Type: Internal
• Operating Temperature: -40°C ~ 85°C
• Package / Case: 256-LBGA
• Lead Free Status / Rohs Status: Details
• Other names: 935293795551

NXP Semiconductors
<Document ID>
User manual
20.10.6.1 Priming transmit endpoints
20.10.6 Operational model for packet transfers
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.
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 must be different
because same methods will not meet USB 2.0 High-speed turnaround time requirements
by simply increasing 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.
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 four endpoints.
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
Priming a transmit endpoint will cause the device controller to fetch the device transfer
All information provided in this document is subject to legal disclaimers.
Rev. 00.13 — 20 July 2011
Chapter 20: LPC18xx USB0 Host/Device/OTG controller
UM10430
© NXP B.V. 2011. All rights reserved.
419 of 1164