MAC address matching with M5223X

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MAC address matching with M5223X

4,386 Views
mjbcswitzerland
Specialist V

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


Labels (1)
0 Kudos
4 Replies

457 Views
DrSeuss
Contributor I
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!)
0 Kudos

457 Views
mjbcswitzerland
Specialist V

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

0 Kudos

457 Views
DrSeuss
Contributor I

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?

0 Kudos

457 Views
DrSeuss
Contributor I
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.
0 Kudos