I have a board with W5500 and ATmega. Software has been ported from W5300 implementation, and works really fine so far.
Now I have the second board with W5500 malfunctioning: SPI access works, I can read and write registers (like VER register with 0x04), open sockets etc. - but I dont get any data transfer.
The only “external” sympton to see is that with no networkcable connected the SPD LED lights, with connecting cable all other three LEDs light up (LNK, DUP, ACT) - which is not normal.
With working boards, only LNK and DUP light up, and ACT flashes with activity.
I solved the first broken board by replacing the W5500, but two broken chips in a small batch are unlikely.
25MHZ oscillation is clear and stable.
The W5500 receives a 1ms /RST pulse, followed by 20ms delay to allow PLL to lock. The init routine does soft reset the chip, set all IPs and MAC, as well as memory, and works as expected.
How can I further track down the source of malfunctioning?
It seems a PHY related problem so far. If I read PHCFGR after hardware reset, it is set to 0xBA. After setting bit 7 of PHYCFGR and resetting it to 0, reading the PHY register returns 0x00 without any changes, no matter what LED is switched on. It seems the PHY is without system clock (I assume hardware reset is async inside chip, while all other actions after reset are synchronous).
How can I make sure the PHY is in working condition?
It’s a mistake on your writing or otherwise?..
PHYCFGR’s reset bit is set by hardware to 1 after a hardware reset.
You can reset the PHY in software by resetting PHYCFGR’s bit7 to zero (0), waiting a few ms and then you must set it manually back to one (1).
That’s what I wrote. Value after hardware reset is 0xba (bit 7 set), but manually writing it to 0 should reset the PHY.
I wrote a 0 - 1 - sequence, but RST bit ist not set to 1 by writing, neither it seems to get set by PHY hardware - so my assumption is that PHY is stuck.
That 0xBA is quite strange… 100Mbps, Half duplex, Link down???
Did you took care of the other bits of PHYCFGR?
Especially those for auto configuration & stuff?
Meaning, did you tried a simple timed sequence like the one below?
It’s OK for a not connected network cable, and has been approved by a WizNet engineer in another thread.
Not necessary, as in normal operation of boards the PHYCFGR is not touched.
PHY is set to “auto” by hardware strap pins and a hardware reset pulse (as i stated already).
You have apparently not understood the problem: with same firmware on a series of boards, one or the other fails with PHY apparently not working correctly. If it was a basic software problem, all boards should be affected, not only a few.
Especially in a PLL based system like the W5500 (and the W5300, which had a similar problem of PLL not working on a low permille level, leading to link up/down being reported with high frequency) I want to understand what electrical parts can affect (or inhibit) correct PLL operation, especially if there is no safe way of getting the operational status of the PLL (like in FPGA PLLs, where a “PLL locked” signal can be routed to the outside world).
It’s not a coding problem, as setting up the W5500 after a hardware reset is not magic.
Maybe one of the WizNet guys could give a statement on that issue?
Solution: Issue fixed. There was one bad solder junction on SMD quartz (flux between solder pad on PCB and quartz). With scope, a clean 25MHz oscillation could be observed (as expected) - apparently the PLL of W55000 didn’t lock correctly.
Question: Is there any legal way to find out if the W5500 PLL has successfully locked, and the IC is operational?
