Not getting LINK LED

[jharvey]

Hey Mark,
I want to thank you for all the help you have provided so far.  The progress we've made would not have been possible without you.

We have everything functioning when our M52235evb is connected directly to a laptop using a crossover cable.

However, we need to put the device on our academic network.  I have talked with ITS and they assign an IP address to a MAC address.

To ensure that we do not conflict with any other MAC addresses on campus, we used an address that started with FF:.....

I've updated the IP configuration variables in application.c including the MAC, IP, Net Mask, Gateway and DNS servers to match with the network I will be plugging into.

I verified that USE_DHCP and USE_UDP are defined in config.h.  I also tried running with the ACTIVE_DHCP commented out and uncommented with no change in results.

However, I do not get a LINK light when I plug the M52235evb into our network and reset the board.

The settings look fine in the "Configure LAN interface" menu after doing a 'show_config':

IP address = 129.CORRECT
MAC address = ff-CORRECT
Subnet mask = 255.255.255.0
Default gateway = 129.CORRECT
LAN speed AUTO
DHCP_SERVER - enabled

* Correct used to replace some of the digits but represent that the values are as expected.

One thing I noticed is that the ARP table is empty.  Should it at least contain the DHCP server?

arp -a
ARP Table contents:
End

I've tried disabling DHCP_SERVER and the same results were seen.

I do not really think I can run WireShark on the network.

This may be a problem with the registration from ITS but I just wanted to see if there is anything you can think could be the problem.

Thank you.
-Jesse

[jharvey]

Also, I tried pinging a machine on the same subnet and it fails on ARP resolution.

ARP resolution started

#
ARP resolution failed

I read the DHCP pdf and did not see anything that could point to my problem in there.

[mark]

Hi Jesse

There are 2 things to consider.

1. The PHY in the M5223X (original silicon which is on all EVBs till now) has a bug with auto-negotiation and so if the link LED is not lighting up it may be that it is not auto-negotiating with the switch/hub which it is now connected to.
To verify this, try connecting to other hubs and switches and verify with your laptop again - if the link goes up with some connections you will need to either use a compatible hub/switch or else set the configuration to fixed 10 or 100M - this always works. (see also under device errata in the tutorial)

2. The first address of the MAC should not be an odd value. This represents a multi-cast address and the Coldfire will ignore it if not set up specially for this - I also got caught out a long time ago as seen here: http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=430&query.id=20184#M430

If  you can find an old (trashed) PC with a network card try to see what MAC address it has. Then you can use this, being sure that it is then unique (assuming the trashed PC will never go back into action again).

Good luck

Regards

Mark

[danh]

Mark,

I saw on the Freescale forum that one of their guys wrote a workaround for this for their demo web server project based on the Interniche tasker and TCP/IP stack. I looked at that and it appears that it only does this "manual autonegotiation" at startup. It seems to me it needs to be an ongoing thing, where you try it not only at startup, but also have some task that periodically checks link state and calls the "manual autonegotiation" function if the link is down. (I know our customers expect that they can connect and disconnect network cables and devices without rebooting anything. They also don't expect to have to manually set the network speed/duplex to match the hub or switch.)

Have you considered adding a workaround for this autonegotiation issue to the M5223x project?

Dan

[mark]

Hi Dan

I have heard that the Freescale example is not a complete solution but I have never tried it myself and also haven't planned on integrating a workaround in the project. I have heard that some users have performed a workaround themselves.

The story is like this:
- The original problem goes back to the MC9S12NE64 and the same problem was inherited by the M5223X
- Freescale informed me (back then) that the bug would be corrected in Q1 2007, so I though that it would not be an issue for real projejcts (there were probably hardly projects delivered before Q1 2007 because the chip supply was still critical at that time).
- But the bug fix didn't come when anticipated so it would probably have been useful to have some automatic search support.
- However rumour has it (I have no official info so this is tentative) that there is now new silicon with the fix available. I don't know whether the fix has been successful nor when it will be delivered. It would however make any workaround redundant.

I am wondering, since there are probably still lots of original devices around, whether it may be best to read the revision number in the chip and start a SW workaround if the new silicon can not be detected....

What do you think?

Regards

Mark

[danh]

Hi Mark,

I have been sort of ignoring this topic while working on other things. Yet I anticipate having to deal with this issue fairly soon.

We already have enough devices with this issue where we will have to deal with it somehow. So I am inclined to agree with your last paragraph below. In fact we have another 5223x-based project based on the Interniche tasker/stack, and the Freescale workaround was successfully integrated into that. (I did not work on that project myself.)

While I am not quite at a point where I can delve into this now, I just did a quick experiment that has me concerned about this link issue:
- With ethernet configured for auto-negotiation, plug into 10/100 hub, link LED lights up and I can ping the board.
- Now plug into 10M hub, the link LED lights up, but I cannot ping the board.
- Plug it back into 10/100 hub, link LED lights up, and I can ping the board again.
- With ethernet configured for NO auto-negotiation, 10M full duplex, I can move back and forth between the two hubs and can always ping it whichever hub it is connected to.
- With ethernet configured for NO auto-negotiation, 100M full duplex, the link LED lights and the board can be pinged when plugged into 10/100 hub, and when plugged into the 10M hub the link LED *does not* light up and of course the board cannot be pinged.

This was with LAN_REPORT_ACTIVITY defined; I tried a few scenarios with that undefined, and the results were the same with regard to the link LED. Note that I am always referring to the link LED which is tied to the LNKLED signal on the 52235 part.

An odd thing is that I have also seen the situation where it is configured for auto-negotiation and *sometimes* works (i.e. can be pinged) when moved back and forth between the two hubs.

But the really concerning thing is that when set to auto-negotiation, the link LED *always* lights up when it's plugged into either hub (and goes out when you unplug of course), and is lit even if the unit is not pingable. So if this indeed the "auto-negotiation" bug with the 5223x part, it seems like the workaround could not rely on the link status as it is currently determined.

Curiously, while typing some stuff here and leaving the board alone, set for auto-negotiation and plugged into the 10M hub, it had not been responding to pings for several minutes and then just started responding without any intervention.

How much of this is consistent with the auto-negotiation issue as you understand it?

Regards,

Dan

[mark]

Hi Dan

I think that the behaviour can be summed up as inconsistent: I never did any great testing of the way that it actually behaves since my feeling was that it basically could not be trusted - neither to get a link nor to display it correctly.

I would expect that more use could be made of the status recovered from the PHY to determine the true state, however I hope that inconsistencies are not discovered when doing this since then it really would be difficult to do things like displaying link state accurately. Therefore we will probably need to do some more work to confirm the real situation.

Regards

Mark