Only ARP works on Demo and Target boards

[fcereja]

Hi Mark,
with the simulator, ping, udp echo ... works well. After downloading the application on either a M52233DEMO or my target board (compiled with CodeWarrior 7.0) only ARP works perfectly.
I first clean the ARP cache on the PC, then I send a ping : with Wireshark, I see the ARP request and response from the board then the ping request and no answer from the board. The ipstat in the debug console reports the ARP frame but 0 ICMP frame. I tested also with UDP and I get the same result. It looks like only frames with Ethertype 0x0806 go through the filter?
I've tryed to find the location in the code where this test is done. Can you please give me some indications where to look at?

Regards
Francis

PS. Autonegociation or fixed speed give the same thing.

[mark]

Hi Francis

Can you check whether perhaps IP offloading is causing a problem?
See: http://www.utasker.com/forum/index.php?topic=290.0
http://www.utasker.com/forum/index.php?topic=180.0

Generally this only affects the simulator when working with connections from the same PC but it may still be worth checking whether it can maybe sometimes also affect real targets.

Otherwise you can debug the reception path (you are obviously basically receiving and transmitting Ethernet frames) by following the PING example in the tutorial: http://www.utasker.com/docs/M5223X/uTaskerV1.3-Tutorial-M5225X.PDF from page 32.

Good luck

Regards

Mark

[fcereja]

Hi Mark,
just an idea : when the PC issues the ARP request, the frame is sent with a broadcast destination MAC address (ff:ff:...). For the other messages, the destination MAC address is the MAC of the board. Is it possible to have a wrong MAC address in the FEC so all frames are rejected by the hardware level?

------------
Yes that was the reason. I've choosen randomly a MAC Address which seems to be a multicast address (07-00-00-00-00-01). According to the user manual of the "MCF52235 ColdFire® Integrated Microcontroller Reference Manual, Rev. 3" page 18-9, the chip performs additionnal tests and the frame was rejected. All works well with a "good" MAC.
I hope my mistake will help other developpers.

Regards
Francis

[mark]

Hi Francis

It is true that if the answer to the ARP request were to contain a different MAC address to the one which is programmed to the MAC it would not be able to work. However I don't think that this is the case since the project doesn't generally make such an error.

However I have another idea. Please see the following http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=437&query.id=52052#M437

Is it possible that you have programmed a MAC address to your boards beginning with a non-zero value? This represents a special form of multi-cast address and it won't receive general Ethernet frame if addressed like that. Ensure that you leave the first byte at 00 to avoid this.

The simulator (and other processors - as far as I can remember) don't distinguish and so will work with such a MAC address. I will adapt the Coldfire simulator to specifically ignore MAC addresses set like this and give an exception to warn the user that it can cause problems on the real target.

Regards

Mark

[Richard]

Hi, Mark.
    You state

Is it possible that you have programmed a MAC address to your boards beginning with a non-zero value? This represents a special form of multi-cast address and it won't receive general Ethernet frame if addressed like that. Ensure that you leave the first byte at 00 to avoid this.

    While that will work, I don't believe that's actually what is required.  Rather, from http://www.iana.org/assignments/ethernet-numbers, I infer that the requirement for avoiding multicast and broadcast is that the second hex digit be even:

These addresses are physical station addresses, not multicast nor
broadcast, so the second hex digit (reading from the left) will be
even, not odd.

    If I understand what's happening, the bytes are sent from left-to-right, but the bits within the bytes are sent from right-to-left, so making the second hex digit be odd results in a 1 as the first transmitted bit, and this is what designates multicast and broadcast.
    Cheers,
        Richard

[mark]

Hi Richard

I expect that you are right about the details. I started to touch on multi-cast addressing when doing some research into IPV6 but didn't get so far that I actually worked with it. I just remember the problem that a non-zero first byte was causing problems on the M5223X (not necessarily on other chips (?)) and by keeping the first byte at 00 avoids the (potential) problem.

Thanks for the input, the link will serve as good reference the next time I get back into the subject.

Regards

Mark