LPC2468FET208,551 NXP Semiconductors, LPC2468FET208,551 Datasheet - Page 263

• Manufacturer Part Number: LPC2468FET208,551
• Description: IC ARM7 MCU FLASH 512K 208TFBGA
• Manufacturer: NXP Semiconductors
• Series: LPC2400r

Specifications of LPC2468FET208,551

• Program Memory Type: FLASH
• Program Memory Size: 512KB (512K x 8)
• Package / Case: 208-TFBGA
• Core Processor: ARM7
• Core Size: 16/32-Bit
• Speed: 72MHz
• Connectivity: CAN, EBI/EMI, Ethernet, I²C, Microwire, MMC, SPI, SSI, SSP, UART/USART, USB OTG
• Peripherals: Brown-out Detect/Reset, DMA, I²S, POR, PWM, WDT
• Number Of I /o: 160
• Ram Size: 98K x 8
• Voltage - Supply (vcc/vdd): 3 V ~ 3.6 V
• Data Converters: A/D 8x10b; D/A 1x10b
• Oscillator Type: Internal
• Operating Temperature: -40°C ~ 85°C
• Processor Series: LPC24
• Core: ARM7TDMI-S
• Data Bus Width: 16 bit, 32 bit
• Data Ram Size: 98 KB
• Interface Type: CAN/I2S/ISP/SSP/UART/USB
• Maximum Clock Frequency: 72 MHz
• Number Of Programmable I/os: 160
• Number Of Timers: 6
• Operating Supply Voltage: 3.3 V
• Maximum Operating Temperature: + 85 C
• Mounting Style: SMD/SMT
• 3rd Party Development Tools: MDK-ARM, RL-ARM, ULINK2, IRD-LPC2468-DEV, SAB-TFBGA208, KSK-LPC2468-PL
• Development Tools By Supplier: OM10100
• Minimum Operating Temperature: - 40 C
• On-chip Adc: 8-ch x 10-bit
• On-chip Dac: 1-ch x 10-bit
• Package: 208TFBGA
• Device Core: ARM7TDMI-S
• Family Name: LPC2000
• Maximum Speed: 72 MHz
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• For Use With: 622-1025 - KIT DEV IND REF DESIGN LPC2468622-1024 - BOARD SCKT ADAPTER FOR TFBGA208568-4358 - DISPLAY QVGA TFT FOR OM10100568-4309 - BOARD EXTENSION LPCSTICK568-4308 - EVAL LPC-STICK WITH LPC2468MCB2400U - BOARD EVAL MCB2400 + ULINK2MCB2400 - BOARD EVAL FOR NXP LPC246X SER622-1005 - USB IN-CIRCUIT PROG ARM7 LPC2K
• Eeprom Size: -
• Lead Free Status / Rohs Status: Lead free / RoHS Compliant
• Other names: 568-4262; 935283234551; LPC2468FET208-S

NXP Semiconductors
UM10237_4
User manual
continuous memory space; even when a frame is distributed over multiple fragments it will
typically be in a linear, continuous memory space; when the descriptors wrap at the end of
the descriptor array the frame will not be in a continuous memory space.
The device driver should enable the receive process by writing a 1 to the RxEnable bit of
the Command register, after which the MAC needs to be enabled by writing a 1 to the
‘RECEIVE ENABLE’ bit of the MAC1 configuration register. The Ethernet block will now
start receiving Ethernet frames. To reduce the processor interrupt load, some interrupts
can be disabled by setting the relevant bits in the IntEnable register.
After the Rx DMA manager is enabled, it will start issuing descriptor read commands. In
this example the number of descriptors is 4. Initially the RxProduceIndex and
RxConsumeIndex are 0. Since the descriptor array is considered full if RxProduceIndex
== RxConsumeIndex - 1, the Rx DMA manager can only read (RxConsumeIndex -
RxProduceIndex - 1 =) 3 descriptors; note the wrapping.
After enabling the receive function in the MAC, data reception will begin starting at the
next frame i.e. if the receive function is enabled while the (R)MII interface is halfway
through receiving a frame, the frame will be discarded and reception will start at the next
frame. The Ethernet block will strip the preamble and start of frame delimiter from the
frame. If the frame passes the receive filtering, the Rx DMA manager will start writing the
frame to the first fragment buffer.
Suppose the frame is 19 bytes long. Due to the buffer sizes specified in this example, the
frame will be distributed over three fragment buffers. After writing the initial 8 bytes in the
first fragment buffer, the status for the first fragment buffer will be written and the Rx DMA
will continue filling the second fragment buffer. Since this is a multi-fragment receive, the
status of the first fragment will have a 0 for the LastFrag bit in the StatusInfo word; the
RxSize field will be set to 7 (8, -1 encoded). After writing the 8 bytes in the second
fragment the Rx DMA will continue writing the third fragment. The status of the second
fragment will be like the status of the first fragment: LastFrag = 0, RxSize = 7. After writing
the three bytes in the third fragment buffer, the end of the frame has been reached and the
status of the third fragment is written. The third fragment’s status will have the LastFrag bit
set to 1 and the RxSize equal to 2 (3, -1 encoded).
The next frame received from the (R)MII interface will be written to the fourth fragment
buffer i.e. five bytes of the third buffer will be unused.
The Rx DMA manager uses an internal tag protocol in the memory interface to check that
the receive data and status have been committed to memory. After the status of the
fragments are committed to memory, an RxDoneInt interrupt will be triggered, which
activates the device driver to inspect the status information. In this example, all
descriptors have the Interrupt bit set in the Control word i.e. all descriptors will generate
an interrupt after committing data and status to memory.
In this example the receive function cannot read new descriptors as long as the device
driver does not increment the RxConsumeIndex, because the descriptor array is full (even
though one descriptor is not programmed yet). Only after the device driver has forwarded
the receive data to application software, and after the device driver has updated the
RxConsumeIndex by incrementing it, will the Ethernet block can continue reading
descriptors and receive data. The device driver will probably increment the
RxConsumeIndex by 3, since the driver will forward the complete frame consisting of
three fragments to the application, and hence free up three descriptors at the same time.
Rev. 04 — 26 August 2009
Chapter 11: LPC24XX Ethernet
UM10237
© NXP B.V. 2009. All rights reserved.
263 of 792