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.
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
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?