ACTLED always on when RJ45 plugged in

TCP/IP Chip W5500
1

i’m a real world EE. my company is building an IOT embedded controller that uses a W5500 and 3 out 4 of our prototypes have the same ethernet problem, which we can not resolve.

prototype number 2 works just fine.

but numbers 1, 3, and 4 all have the same problem: shortly after plugging an ethernet cable in the link led comes on (correctly) and then the active led comes on and stays on even when there is no real ethernet activity. those prototypes neither send nor do they seem to receive network traffic, although they appear to be correctly configured.

we’ve checked all four prototypes carefully using a stereo microscope and can find nothing wrong or different between them.

our PCB is based on your published reference schematics and we are using the J1B1211CCD RJ45 jack with magnetics. W5500 pins 38 thru 47 are all open (to save PCB space). we could tie them directly to VCC/GND (as appropriate) if that is considered acceptable. according to the data sheet PMODE2…0 have internal pull-ups, which is how we want the chip configured. all other W5500 pins are connected as recommended. we have tested using both 33 ohm ond zero ohm resistors for R21 thru R24 and see no dfference with respect to this problem. most of our testing has been done using zero ohm resistors; prototype number 2 has about 200 hours of successful test time with R21…24 set to zero ohms.

we have several different test programs and they seem to show that everything is ok on the spi interface - we can read and write registers with no errors.

with no cable plugged in, PHY_CFG reads as 0xBA. with a cable plugged in it reads as 0xBF.

while this is the first time that we’ve used a wizet chip, we’ve built many ethernet products using atmel and freescale processors and a variety of ethernet switch chips. those parts all have registers that we can read that help with troubleshooting, but the W5500 seems not to have any detailed status registers.

do you have any suggestions as to what might be wrong?

are there any registers that are not mentioned in the datasheet (or any pins) that might help us figure out what we’ve done wrong?

any suggestions or help would be much appreciated and we can provide you with the schematic if you so desire.

thanks, andy

2
  1. MAC address you use?
  2. Activity LED is always on, or continuously blinking? Check switch/hub side port connected to the chip. I use W5100, and sometimes I see weird behavior when W5100 activity led starts intensely flashing, when there should be no activity on the port. I think it is caused by issue negotiating between hub and W5100 ports and thus packet storm on this specific link. If your switch/hub port also shows abnormal “activity”, it might be the case.
3

Eugeny, thank you for your very quick response; i read it within the hour but i’ve waited to respond till i have more information.

fyi, we use two types of s/w to test new hardware: fully functional programs - in this case an embedded web server; and design verification routines, which we call DVRs - in this case code that uses the spi interface to read and write certain registers utilizing as much checking code as the underlying h/w permits.

  1. the embedded web server was essentially lifted from the arduino sample web server and retains its ‘DEADBEEFFEED’ mac address. the dvr does not set a mac address. if i understand phy negotiation correctly, the mac address only becomes relevant long after phy negotiation is successfully completed.

  2. at the W5500, very shortly after the RJ45 cable is plugged in (at both ends) the link led comes on and stays on followed, a couple of seconds later by the active led. scoping both signals, there are no signs of any edges after the initial edges. the computer at the ‘other end’, which i will call the client, and which is a lenovo W510 running win 7 (and which, i think, is fully updated) shows a link led very shortly after the second cable connection is made. shortly after that the client’s active led blinks a bunch of times. these blinks seem - using wireshark to view the trafic in near real time - to correspond to the sending of windows network discovery packets. wireshark shows no inbound traffic.

meanwhile, my attention was caught by michael boehmer’s september 2014 posting on this forum entitled “W500 - SPI OK, no TX/RX”. many years ago i was paid a lot of money to sort out another engineer’s screwed up PLL design and in that and other situations i learned how flaky PLLs can be as well as appreciating the value of ‘PLL locked’ status bits.

there being no PLL locked status bit on the W5500 (at least, not such a publically disclosed bit) i started looking at the XI and XO signals (W5500 pins 30 and 31).XO looked beautiful and XI, which was about 160 degrees out of phase with XO looked ok, but not very pretty.

while pondering the implications of that, i noticed that the active led had started behaving itself and wireshark was showing bi-directional traffic. further playing around led to the conclusion that the clock circuit is fairly unstable; perhaps being good enough to read and write registers but not being good enough to keep the PLL both locked and delivering a clean 150 mHz clock.

to conserve PCB space we are using a 25 mHz resonator (Murata CSTCW25MOX53-R0, digikey 490-11074-1-ND) which contains 15 pf capacitors as opposed to the 18 pf specified by wiznet. for whatever reason, there do not seem to be any 18 pf 25 mHz resonators. if 15 pf versus 18 pf is the sole cause of clock instability, i’d be somewhat surprised.

nevertheless, i added a 6 pf (that being the smallest cap in the lab) ceramics to each side of the resonator and the clock now seems stable, although attaching a scope probe to XI seems to kill the phy.

i can’t help but notice the number of posts on this forum that might involve a phy clock problem - often they don’t seem to have a definitive resolution - and coupled with the fact that this is the first time that a PCB of mine has encountered a clock problem (out of quite a lot of PCBs) i find myself wondering if the W5500’s PLL might be prone to instability.

in any event, our next step will be to spin the PCB to replace the resonator with a crystal and discrete caps and see what happens. probably we’ll add pads for R17 to facilitate loop gain analysis.

andy

4

Datasheet of resonator you use says frequency tolerance is 0.5%, W5500 datasheet says 30 ppm (0.03%). I think you are on the right course, and replacing with appropriate quartz crystal oscillator will solve the issue.

Read Wikipedia about MAC address, probably using DE as first byte may not be a good idea in wider application sense, and would be good to set really unique address for each board and have method developed for choosing it.