topic Re: MAC address matching with M5223X in ColdFire/68K Microcontrollers and Processors

MAC address matching with M5223X

mjbcswitzerland — Thu, 22 Jun 2006 06:37:26 GMT

Hi All

I was playing around with the M52235EVB today.

I set several MAC addresses and checked that ARP, ping and an embedded web server were working correctly.

These are the addresses which I used:

00-00-00-00-00-00
00-00-00-00-00-11
00-00-00-00-11-22
00-00-11-22-33-44
00-11-22-33-44-55
11-22-33-44-55-66
66-55-44-33-22-11

In each case ARP works fine. The device responds to the broadcast with its MAC address (as shown in the list) and the PC then displays the IP/MAC combination in its ARP table (I delete the ARP table in the PC with arp -d between tests)

In each case pings and the web browser operate correctly with the exception of the MAC address 11-22-33-44-55-66. No frames are received with the MAC destination, only broadcasts.

Can any one reproduce this or explain why the one address (or some sort of combinations) would not work?

Many thanks for ideas.

Regards

Mark Butcher

www.mjbc.ch

Re: MAC address matching with M5223X

DrSeuss — Mon, 26 Jun 2006 06:28:55 GMT

This is a multicast address, and the syptoms are consistent with this.
The address really should not be used. To be safe, always make the first octet a zero (never odd!)

Re: MAC address matching with M5223X

mjbcswitzerland — Mon, 26 Jun 2006 07:10:07 GMT

Thanks Doc

But has this to do with the operation of the MAC compare unit, even when all unicast and multcast features are disabled in the EMAC? I was expecting it to simply do a compare of the 48 bit MAC and either match it with the value programmed or reject it. This must mean that it is more than just a 48 bit comparator working there...(?).

Regards

Mark
www.mjbc.ch

Re: MAC address matching with M5223X

DrSeuss — Tue, 27 Jun 2006 07:31:22 GMT

I misspoke in that I was thinking of pause frames (01:80:C2:00:00:01).

Perhaps, this is an error that has been worked around for a long time. It is possible that the FEC trashes ANY frame with an odd first oclet.

I am referring to sec 18.4.8 in the specification. Per flow chart it appears that ANY odd first oclet is assumed to be a pause frame. There is more going one than a simple compare.

Can you run your test again to determine if all odd first oclets are trashed?

What about the pause frame above?

Re: MAC address matching with M5223X

DrSeuss — Wed, 28 Jun 2006 00:42:18 GMT

I spoke this the experts this morning and it was explained to me that the pause frames are just special forms of the mulitcast.

The ColdFire_lite stack does not use the Group Hash table so any address with the odd first oclet is ignored. This configuration is in the ifec.c driver.