Hi group,

I have a demo application here doing network IO over the ethernet mac
that works like a charm with 10Mbit speed. However, if I hook the board
up to 100Mbit, the best thing I can get to is a very much delayed
processing of 100Mbit frames. It seems like the MAC gets the frames with
a delay of several seconds only from the PHY. The funny thing is no
frames are lost! They just arrive with a delay of several seconds. I can
monitor that the frames are sent to the design using wireshark, then
measure when the breakpoint in the recive interrupt routine is hit - big
delay - absolutely reproduceable.

I tried various PHY initialisations according to the users manual and
several sources around the net (i.e. also according to the easy Web demo
found here in the files section). However, 100Mbit does either not work
at all (that's the case with the easy web code) or as described with
very much delay. I tested this with two different hardware designs and
the '-' as well as the 'A' chip revisions. It always works just fine
with 10Mbit conections!

Any ideas?

TIA

Markus
Start a New Thread

In answering my own question, I can say that I've ben able to iron this
out. The problem was that the demo board (and as a result mine too) were
using a 6Mhz crystal which aparently is a too low frequency to propperly
drive the internal MAC PLL. Switching to a 12Mhz crystal solved the problem.

All frames the mac was reciveing at 100Mbit previousely had overrun
errors, and the mac - after reciveing a frame - therefore was waiting
for more data to arrive from the PHY to complete the frame. A next
arriveing frame then triggered the delivery of the previous one. That's
where the delay came from.

While we are at it, the LPC user manual contains an error in the section
describing the MAC adress registers. That's why demo code found on the
net always sets the unicast bit (thereby actually putting the MAC into
promisious mode) in order to recive any frames unicast at all. Needless
to say that this is a bad aproach for a resource constrained embedded
system. Aparently the people at NXP think that the "first octet" of the
MAC acutally is the last one and so on. As soon as one stores the MAC
this way:

MAC_SA0 = ( OurMac[5] << 8 ) + OurMac[4];
MAC_SA1 = ( OurMac[3] << 8 ) + OurMac[2];
MAC_SA2 = ( OurMac[1] << 8 ) + OurMac[0];

Where "OurMac[5]" denotes the LAST byte of a MAC (when reading it from
left to right) and "OurMac[0]" is the first one, everything starts to
work propperly.

Does anyone know where at NXP I could send this documentation error to
so as it gets corrected?

Anyways, might be that this information helps others when reading the
archives of this group. At least my high performance, multi connection
networking stack which implements ARP, IP, ICMP, UDP, TCP, DHCP and DNS
resolver code now works like a charm :-)

Markus

Markus Zingg schrieb:
> Hi group,
>
> I have a demo application here doing network IO over the ethernet mac
> that works like a charm with 10Mbit speed. However, if I hook the board
> up to 100Mbit, the best thing I can get to is a very much delayed
> processing of 100Mbit frames. It seems like the MAC gets the frames with
> a delay of several seconds only from the PHY. The funny thing is no
> frames are lost! They just arrive with a delay of several seconds. I can
> monitor that the frames are sent to the design using wireshark, then
> measure when the breakpoint in the recive interrupt routine is hit - big
> delay - absolutely reproduceable.
>
> I tried various PHY initialisations according to the users manual and
> several sources around the net (i.e. also according to the easy Web demo
> found here in the files section). However, 100Mbit does either not work
> at all (that's the case with the easy web code) or as described with
> very much delay. I tested this with two different hardware designs and
> the '-' as well as the 'A' chip revisions. It always works just fine
> with 10Mbit conections!
>
> Any ideas?
>
> TIA
>
> Markus
>
Start a New Thread

Paul,

Yep, the figure would help interpreting it correctly, and I admitt that
I did not look at it during dealing with setting the MAC cause the
figure is in a paragraph of the doc giving what it seems to be a general
overview on ethernet.

Regarding other sample code, I.e. the GNU EasyWeb code in the files
section of this group (emac.c file) also seems to do it wrong like the
following code snippet shows:

/* Set the Ethernet MAC Address registers */
MAC_SA0 = (MYMAC_1 << 8) | MYMAC_2;
MAC_SA1 = (MYMAC_3 << 8) | MYMAC_4;
MAC_SA2 = (MYMAC_5 << 8) | MYMAC_6;

/* Initialize Tx and Rx DMA Descriptors */
rx_descr_init ();
tx_descr_init ();

/* Receive Broadcast and Perfect Match Packets */
MAC_RXFILTERCTRL = RFC_UCAST_EN | RFC_BCAST_EN | RFC_PERFECT_EN;

MYMAC is defined in emac.h like this:

#define MYMAC_1 0x00 /* our ethernet (MAC)
address */
#define MYMAC_2 0x30 /* (MUST be unique in
LAN!) */
#define MYMAC_3 0x6C
#define MYMAC_4 0x00
#define MYMAC_5 0x00
#define MYMAC_6 0x02

It does not look like 02 00 00 would be a valid OUI (where 00 30 6C
seems to be one), so it seems that the author of this code (aparently
someone from Keil cause their code is having the same bug) like it first
happened to me also interpreted it the wrong way.

It's hard to be sure but the fact that they turn on UNICAST
(RFC_UCAST_EN) (cause otherwise they would no be able to recive frames
directly targeted at them, but do not make note of this in the comment)
along with the naming of their MYMAC constant and what they had defined
for the MYMAC at least strongly seem to indicate it.

So, I agree that the doc is correct, but it's very misleading at the
same time too. Sad fact is also that the mentioned Easy Web example is
likely to be the one most often used examples as a base due to it's wide
spread availablilty along with the fact that it's implemented for a lot
of different hardware designs.

Markus

Paul Curtis schrieb:
>
> Markus,
>
> > While we are at it, the LPC user manual contains an error in the
> > section describing the MAC adress registers. That's why demo code
> found on
> the
> > net always sets the unicast bit (thereby actually putting the MAC into
> > promisious mode) in order to recive any frames unicast at all. Needless
> > to say that this is a bad aproach for a resource constrained embedded
> > system. Aparently the people at NXP think that the "first octet" of the
> > MAC acutally is the last one and so on. As soon as one stores the MAC
> > this way:
> >
> > MAC_SA0 = ( OurMac[5] << 8 ) + OurMac[4];
> > MAC_SA1 = ( OurMac[3] << 8 ) + OurMac[2];
> > MAC_SA2 = ( OurMac[1] << 8 ) + OurMac[0];
> >
> > Where "OurMac[5]" denotes the LAST byte of a MAC (when reading it from
> > left to right) and "OurMac[0]" is the first one, everything starts to
> > work propperly.
>
> Have you looked at Fig 19 in the 23xx UM rev. 01, Markus? That states that
> octet 1 which must be stored in SA0 is the last octet in the address when
> read left to right. NXP number the octets 6 through 1 in packet byte order
> so I think NXP's description is correct and your code is also correct.
> Whether other code available on the net is right, I don't know.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
>
Start a New Thread