Hi All
Since I have the Ethernet controller in action, here's a report on what I did and what I found.
Comments welcome!
Regards
Mark
Ethernet Controller with PHY
This is certainly the most interesting part of the LM3S6965. It has not just an integrated Ethernet controller but also an Ethernet physical interface device, which promises to make the device extremely attractive.
The Freescale M5223X devices also have these on-board but its physical interface device doesn’t perform automatic MDI/MDI-X cross over correction which allows connecting with either a straight or cross-over cable. This avoids troubles with cable types when connecting directly or via a switch/hub and is therefore a big plus point.
Slightly surprising is the fact that the MDO line on the internal MII interface (the MDIO signal) needs an external 10k pull-up resistor to operate correctly. This MDIO signal is the only one available externally on its own dedicated pin.
Unlike the M5223X, which requires a single 25MHz crystal so that it can accurately generate the required internal Ethernet clocks, the LM3S6965 requires two crystals: One for the CPU and a second of 25MHz for the PHY.
There is no physical address (usually a 6 bit value) to address the PHY since there is only one possible PHY in the system – the M5223X for example can be configured to use alternative PHYs by disabling the internal PHY and accessing the external one via MII lines multiplexed with GPIOs. An external MII interface allows other media interfaces to be used in stead of Ethernet - such as optical, wireless or power line modem etc.
The LM3S6965 contains dedicated TX and RX FIFO Ram for use with the Ethernet controller. The TX buffer can hold one frame to be transmitted and a number or RX frames, depending on the size of individual receptions. These buffers are each 2k in size – experience has shown that a number of RX buffers can be useful for avoiding overruns at the receiver so it will be interesting whether the 2k RX buffer may prove to be a weakness by this device…
FIFO accesses are long word accesses which makes it more efficient that a byte oriented interface.
Due to the FIFO operation, the receive software can not perform zero copy processing since the buffers can not be accessed in a memory mapped fashion. Also it is in interest of avoiding overruns to retrieve the data as fast as possible by copying it into a memory mapped receive buffer – the number of which could be configurable. The question is whether the Rx FIFO copy should be performed in the Rx frame interrupt routine or not. It is probably best to do it asap. to reduce the likelihood of Rx overruns but the interrupt will need to allow other interrupts to operate (in other words have quite a low priority in the system hierarchy) since the copy loop will inevitably take around 200us or so for full sized Rx Ethernet frames. Since the Cortex M3 code handles nested interrupts well, this should not be a big issue.
On the transmission side there is a small complication involved due to the fact that the length of the transmit frame must be put into the TX FIFO as the first 2 bytes. This can complicate since TCP/IP frames are often built up in packets (Ethernet frame, IP frame, TCP frame, TCP data etc.) and these packets are placed in to an output buffer (not necessarily in the same order as the packets to be sent) and the total length is not necessarily known until the complete frame has been constructed.
The FIFO operation is certainly less flexible but compatibility can be easily maintained by first constructing the frame in a buffer (this requires additional memory copies and the space for this buffer) and then copying it to the FIFO once it is complete in linear memory and the total length is known.
As long as the buffers are correctly aligned (long word boundaries) the actual FIFO copies are optimally efficient because they become long word copies without any byte manipulation.
The first exercise was to be able to respond correctly to ARP and PING requests and this was achieved by using the technique of copying the RX FIFO to a series of correctly aligned RX Ethernet frame buffers and building up the transmission data in a correctly aligned TX Ethernet frame buffer. The PHY was programmed to generate an interrupt on link status changes so that the present link state and speed is known.
During the ARP response transmission the operation of the PADEN (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.
The LEDs (LED0 and LED1) are controlled by the PHY. If the control of the general purpose ports, which they share with, are configured to activate the peripheral function the LED0 lights on link OK and LED1 flashes on RX or TX activity. A variety of other LED functions can also be programmed in the PHY’s LED configuration register!
The basic operation of the Ethernet interface could be successfully verified. Although it is not the highest performance solution due to the FIFO operation and lack of DMA support directly to working memory, the PHY and MAC are very easy to use. A useful optimisation step, which will be looked at later, is to remove the present linear TX frame buffer and build up the layers of TCP/IP frames directly in the TX FIFO – this will avoid a memory copy stage but the frame length issue (as described above) will have to be solved – there are certainly tricks which can be worked out to do this somehow.
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.
Ethernet Power Consumption
100M Ethernet operation involves a certain amount of power consumption. This often causes devices with integrated PHY to get rather warm and so it was interesting to note that the LM3S6965 doesn’t run hot at all. It gets only slightly warm, which is hardly noticeable in comparison to other devices like the MC9S12NE64!
The actual current consumption is not specified in the data sheet and it is difficult to measure it since the evaluation board is supplied via the USB cable. Figures will be added once such measurements have been made – either using a special USB cable or on a different board.
A final note: the LM3S6XXX Ethernet controller has been added to the uTasker simulator, allowing it to be used for projects running in the uTasker environment.
The following currents were measured using the LM3S6965 evaluation board, supplied from the 5V USB bus.
1. Board held in reset - 95mA - current consumption is assumed to be mainly for the board peripherals such as the JTAG debug interface.
2. LAN set to 10MHz fixed speed with no LAN connection - CPU running at 50MHz - 125mA
3. LAN set to 10MHz fixed speed with LAN link up - CPU running at 50MHz - 128mA
4. LAN set to 100MHz fixed speed with no LAN connection - CPU running at 50MHz - 144mA
5. LAN set to 100MHz fixed speed with LAN link up - CPU running at 50MHz - 190mA
If the reset current is removed, this gives full speed 100MHz LAN operating current of 95mA, which is very impressive indeed...!!!
