Author Topic: Ethernet controller  (Read 17218 times)

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3103
    • View Profile
    • uTasker
Ethernet controller
« on: November 25, 2007, 05:06:23 PM »
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.


Offline freewill78

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Ethernet controller
« Reply #1 on: January 14, 2009, 02:55:21 PM »
Hi Mark,

We are in need of an immediate solution for LPC2368 to work as a FTP client, that can connect to a remote ftp server and make file transfer(download). Do you thnik it is a piece of cake with your rtos, or significant effort still be required?

Thanks,
FreeWill

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3103
    • View Profile
    • uTasker
Re: Ethernet controller
« Reply #2 on: January 14, 2009, 03:51:52 PM »
Hi Freewill

The package contains an FTP server but not a client.

I know that a few users have expressed interest in having client capabilities and possibly some have added it for their own projects.
Since all necessary elements required for client operation and file transfers is available it is not a big job to make client functionality work. The only "trickier" bit is the fact that the client has to manage login and two TCP connections (the control and transfer connections) and also 'should' support both active and passive transfers to ensure that it will work with all server types. Therefore it is a bit more complicated than a simple application client or application server but I wouldn't expect more that a day's work of so to do it (it can all be developed and tested in the uTasker simulator which is much faster than doing it on target hardware).

If you are interested in using the uTasker for a commercial project this feature can also be added (with support) based on a full license purchase.

Regards

Mark

Offline freewill78

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Ethernet controller
« Reply #3 on: January 15, 2009, 05:04:30 PM »
Hi Mark,

Thank you for the quick reponse. I've been investigating all options and RTOS, TCP/IP Stacks etc for two days.
Still I like the utasker. :)
I'm sending my comments via private messaging in a few minutes...

Offline michal_dvorak

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Ethernet controller
« Reply #4 on: April 09, 2009, 11:03:30 AM »
Hello Mark,
 we have one project with LPC2387 (My colleague Forrest works on that). Due to costs of PHY DP83848 we would like to change to another vendor of PHY -> LAN8700 from SMSC (it's 3 times cheaper than DP83848). It also supports RMII.
 I would to ask you what is your opinion - if it's lot of work to support LAN8700? The errata on first silicon is on LPC processor or on the PHY DP83848?

 thank you, regards, Michal

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3103
    • View Profile
    • uTasker
Re: Ethernet controller
« Reply #5 on: April 09, 2009, 12:12:11 PM »
Hi Michal


The LPC23XX project supports two types of evaluation board, the one from Keil with NATIONAL PHY DP83848 and the one from Olimex with the MICREL KS8721. All PHY devices have a basic compatibility so it doesn't really make a big difference which ones are used for standard Ethernet applications.

These are the changes to match the project to each chip (in app_hw_lpc23xx.h).


#ifdef OLIMEX_LPC2378_STK                                                    // MICREL PHY KS8721
    #define PHY_ADDRESS_ (0x01 << 8)                                         // address of PHY on OLIMEX LPC2378-STK (RMII mode)
    #define PHY_IDENTIFIER          0x00221619                               // MICREL identifier
    #define PHY_MASK                0xfffffff0                               //
#elif defined KEIL_MCB2300                                                   // NATIONAL PHY DP83848
    #define PHY_ADDRESS_ (0x01 << 8)                                         // address of PHY on KEIL MCB2300 (RMII mode)
    #define VNDR_MDL      0x09                                               // Vendor model number
    #define MDL_REV       0x00                                               // Model revision number
    #define PHY_IDENTIFIER          (0x20005c00 | (VNDR_MDL<<4) | MDL_REV)   // NATIONAL DP83848 identifier
    #define PHY_MASK                0xfffffff0
#endif


If you use a different type the only modifications that should be required are to match its ID and ensure that its physical address matches the hardware. There shouldn't be any real difficulty involved.

The first LPC23XX version has some issues which means that the number rx LAN buffers was restricted to 5 and the RMII mode had to be set. The driver code reads the chip ID and automatically adjust the RMII setting accordingly. There are no errors at the PHY side that need to be respected.

Regards

Mark


Offline michal_dvorak

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Ethernet controller
« Reply #6 on: May 21, 2009, 01:00:26 PM »
Hello Mark,
 finally we have successfuly using LAN8700, but there was some troubles around RX_ER pin on PHY chip. It cannot be pulled high during boot-up sequence, otherwise it's not working properly. But LPC processor has default state pull-up on every pins.
 
 I have question to you - does uTasker use this pin P1_14/Ethernet_RX_ER ?? It seems to me that not, despite of there is some initialization in fnConfigEthernet() function ....
 In RMII description there is written, that it's optional pin.

 thank you for replay, Michal

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3103
    • View Profile
    • uTasker
Re: Ethernet controller
« Reply #7 on: May 21, 2009, 07:40:45 PM »
Hi Michal

In the Ethernet controller initialisation the RX_ER pin is indeed configured for this use.
The two PHY that are supported as standard (Micrel KS8721BL and DP83848) both have this connection and the standard evaluation boards also connect it.

The pin is used for signaling between the Ethernet controller (MAC) and the PHY but not directly by the driver.

If you find that you don't need to connect it you can configure this after the Ethernet initialisation (which generally takes place as one of the first jobs after initialisation) back to any alternative use.

Regards

Mark

Offline aaronlawrence

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: Ethernet controller
« Reply #8 on: June 15, 2010, 07:41:15 AM »
As a note on this topic, that may be helpful for others.
Indeed the LPC23xx has (by default) a weak pullup on all lines. This means that the RX_ER, which also serves to configure the PHY Address, may get a high value at reset and thus the PHY would be at address 1 insetad of 0 as uTasker expects.
We added a stronger 10k pulldown on RX_ER/PHY_AD0 and this problem was resolved without needing to change other things.
Or so it seemed... we are still struggling with the LAN8720.