LPC1767FBD100,551 NXP Semiconductors, LPC1767FBD100,551 Datasheet - Page 179

• Manufacturer Part Number: LPC1767FBD100,551
• Description: IC ARM CORTEX MCU 512K 100-LQFP
• Manufacturer: NXP Semiconductors
• Series: LPC17xxr

Specifications of LPC1767FBD100,551

• Core Processor: ARM® Cortex-M3™
• Core Size: 32-Bit
• Speed: 100MHz
• Connectivity: Ethernet, I²C, IrDA, Microwire, SPI, SSI, UART/USART
• Peripherals: Brown-out Detect/Reset, DMA, I²S, Motor Control PWM, POR, PWM, WDT
• Number Of I /o: 70
• Program Memory Size: 512KB (512K x 8)
• Program Memory Type: FLASH
• Ram Size: 64K x 8
• Voltage - Supply (vcc/vdd): 2.4 V ~ 3.6 V
• Data Converters: A/D 8x12b, D/A 1x10b
• Oscillator Type: Internal
• Operating Temperature: -40°C ~ 85°C
• Package / Case: 100-LQFP
• Processor Series: LPC17
• Core: ARM Cortex M3
• 3rd Party Development Tools: MDK-ARM, RL-ARM, ULINK2, MCB1760, MCB1760U, MCB1760UME
• For Use With: 622-1005 - USB IN-CIRCUIT PROG ARM7 LPC2K
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• Eeprom Size: -
• Lead Free Status / Rohs Status: Details
• Other names: 568-4967; 935289808551

NXP Semiconductors
UM10360
User manual
The Ethernet block includes two DMA managers. The DMA managers make it possible to
transfer frames directly to and from memory with little support from the processor and
without the need to trigger an interrupt for each frame.
The DMA managers work with arrays of frame descriptors and statuses that are stored in
memory. The descriptors and statuses act as an interface between the Ethernet hardware
and the device driver software. There is one descriptor array for receive frames and one
descriptor array for transmit frames. Using buffering for frame descriptors, the memory
traffic and memory bandwidth utilization of descriptors can be kept small.
Each frame descriptor contains two 32-bit fields: the first field is a pointer to a data buffer
containing a frame or a fragment, whereas the second field is a control word related to
that frame or fragment.
The software driver must write the base addresses of the descriptor and status arrays in
the TxDescriptor/RxDescriptor and TxStatus/RxStatus registers. The number of
descriptors/statuses in each array must be written in the
TxDescriptorNumber/RxDescriptorNumber registers. The number of descriptors in an
array corresponds to the number of statuses in the associated status array.
Transmit descriptor arrays, receive descriptor arrays and transmit status arrays must be
aligned on a 4 byte (32bit)address boundary, while the receive status array must be
aligned on a 8 byte (64bit) address boundary.
Ownership of descriptors
Both device driver software and Ethernet hardware can read and write the descriptor
arrays at the same time in order to produce and consume descriptors. A descriptor is
"owned" either by the device driver or by the Ethernet hardware. Only the owner of a
descriptor reads or writes its value. Typically, the sequence of use and ownership of
descriptors and statuses is as follows: a descriptor is owned and set up by the device
driver; ownership of the descriptor/status is passed by the device driver to the Ethernet
block, which reads the descriptor and writes information to the status field; the Ethernet
block passes ownership of the descriptor back to the device driver, which uses the status
information and then recycles the descriptor to be used for another frame. Software must
pre-allocate the memory used to hold the descriptor arrays.
Software can hand over ownership of descriptors and statuses to the hardware by
incrementing (and wrapping if on the array boundary) the
TxProduceIndex/RxConsumeIndex registers. Hardware hands over descriptors and
status to software by updating the TxConsumeIndex/ RxProduceIndex registers.
After handing over a descriptor to the receive and transmit DMA hardware, device driver
software should not modify the descriptor or reclaim the descriptor by decrementing the
TxProduceIndex/ RxConsumeIndex registers because descriptors may have been
prefetched by the hardware. In this case the device driver software will have to wait until
the frame has been transmitted or the device driver has to soft-reset the transmit and/or
receive data paths which will also reset the descriptor arrays.
Sequential order with wrap-around
When descriptors are read from and statuses are written to the arrays, this is done in
sequential order with wrap-around. Sequential order means that when the Ethernet block
has finished reading/writing a descriptor/status, the next descriptor/status it reads/writes is
All information provided in this document is subject to legal disclaimers.
Rev. 2 — 19 August 2010
Chapter 10: LPC17xx Ethernet
UM10360
© NXP B.V. 2010. All rights reserved.
179 of 840