Hi All
Since I (finally, after some battling with the PHY) have the Ethernet controller in action, here's a report on what I did and what I found.
Comments welcome!
Regards
Mark
Ethernet Controller
The LPC2378 contains an Ethernet controller but this requires an external physical layer interface device (PHY) and the National Semiconductor’s DP83848 is used on the MCB2300. The PHY is connected via RMII (Reduced Media Independent Interface) rather than MII, but not because the MII mode is not possible. The RMII mode saves some pins: where the MII mode defines 16 pins, the RMII needs only 6 to 10.
In order to achieve the same throughput as MII the RMII needs a faster clock (50MHz rather than 25MHz).
When configuring the Ethernet controller, the RMII ports are configured for their peripheral operation. The Ethernet module is powered up and the MII management clock set to 2.5MHz (the DP83848 can actually communicate up to 25MHz but the specification stipulates 2.5MHz). The ID of the PHY is read to ensure that this is correctly identified before continuing. The PHY address on the MCB2300 is 1 – it is possible to connect up to 31 PHYs on the RMII, determined by input states to the DP83848 at reset.
Due to a bug in the first silicon, a workaround is needed to get the RMII mode operating. This involves checking the MAC module ID, to see whether the workaround is needed, and configuring P1.6 in the PINSEL2 register to be ENET-TX_CLK. P1.6 can therefore not be used for other functions if it is not sure that the chip is at least an A revision.
To ensure that the PHY is operating correctly, its identifier is requested and checked with the identifier expected from the PHY type.
Since the interrupt output from the DP83848 is not connected to the processor on the MCB2300 no link state change interrupt was integrated.
The LPC2378 has 16k of RAM which is specially positioned on the internal bus to allow it to be used optimally by the Ethernet controller. This RAM is not grouped together in the memory map with the other RAM modules in the chip and so it was decided to use it especially for the Ethernet. A special memory allocation routine (uMallocLAN_Align()) was added to support this and the user can specify how many receive buffers and how many transmit buffers are allocated there. Since there is space for 10 full size Ethernet buffers a good choice would be 6/7 for reception and 4/3 for transmission – but this is not possible when working with the first silicon due to a problem with the receiver not being able to handle more than 4 buffers. If the chip is at least a revision A type this restriction no longer applies.
The project was thus set up to use 4 receive buffers and 6 transmit buffers in the Ethernet RAM space. If it is sure that only newer devices are in use this can be modified to use more receive buffers, since these are more critical.
As well as the Ethernet data buffer space in the Ethernet RAM, a status block and a buffer descriptor is created in the same RAM for each receive and transmit buffer.
The MAC address is set to the registers SA0, SA1 and SA2.
The first exercise was to be able to respond correctly to ARP and PING requests. No transmit interrupt was required since the transmit buffer descriptors hold information about how far the transmission of open buffer has progressed.
Each frame reception generates an RX_DONE interrupt and this interrupt was used to wake the Ethernet reception task to process the contents of the frame. Once the frame had been processed, the user index (receive consumer) is incremented to the next buffer.
During the ARP response transmission the operation of the PAD_CRC_ENABLE (padding enable) was verified. This is a feature which allows Ethernet frames of less than 60 bytes to be automatically padded to the minimum length. This was verified to be padding with zeros up to the minimum Ethernet frame size of 60 bytes. Padding with zeros is important to avoid broadcasting the remains of previous TX FIFO buffer content, which can represent a security risk in some applications. Since the device does this correctly, no manual padding is required.
It can be concluded that the Ethernet controller in the LPC2378 is a powerful solution with high speed RAM dedicated to the job of transmitting and receiving the frame contents. 16k Ethernet RAM allows fairly generous buffer space. Due to a bug in the original silicon, the limit to the number of receive buffers means that this can not be utilised optimally but when using revised devices this is no longer an issue.
The Ethernet controller supports various powerful features which haven’t been discussed here (eg. the various set ups to receive certain types of unicast and multicast and wake up frames). Although the use of the receive and transmit buffers is very simply, the complete set up is a little more complicated due to its range of capabilities. Some of the modes are not that easy to understand and may require quite a lot of experimenting to set up and use correctly.
The present solution state uses standard configurations which have proved to work reliably during the first ARP/ICMP PING test phase.
The next step is however to add the uTasker HTTP and FTP servers. These require the uFileSystem to be able to do anything useful so this requires the porting of the uFileSystem and parameter system – involving manipulating internal FLASH, which is the next step in the development process.
