Sorry it this is in the wrong spot. We are using the WIZ850io modules which use the w5500 chip for a device. It will connect and work fine for awhile, then we will get the activity LED on the module to stick on. It will stay on after a software reset or toggling the reset pin low for 500ms then back high. Once this occurs the device will reconnect but in a strange way. Ping request may or may not be answered. We have 3 sockets in use one for a tcp connection one for udp and another tcp socket. once the device gets in this state they all become unstable. The only way to get it back to a good state is to remove power from the device.
W5500 thinks it receives something. Sounds like PHY issue.
This is strange because hardware reset is expected to reset PHY, and after hardware reset the behavior must change (may continue ACT being lit, or return to normal service).
I have similar situation with W5100 sometimes, not exactly the same though. Hub device ASUS GX1005B, something when powering W5100 connected to it chip shows constant activity, while thereāre no packets on the wire. Hardware reset solves the issue. And it only happens with this hub, I tried several other devices, no problems with them.
Thus please try connecting with (or through) another network device to see if behavior will change. Also detail if ACT LED turn on steady or blinks like thereās something on the wire. If it is lit steadily then it may be the sign of lock-up, and thus power quality is under suspicion.
Thank you for the reply. I have tried 2 other network switches both from different manufacturers. I can do this while it is in this state and no difference. I will double check my power but I donāt believe that to be the issue unless this device is very very sensitive. We also have a couple of ADC and op amps for different analog measurements and I need it to be clean for these.
It doesnāt happen often and I really have to push it to get it into this state. I am leaning towards an ungraceful disconnect from the server it connects to.
Sorryā¦ with pushing it I meant the amount of data that we are transmitting.
ACT LED is steady. no blinking unless I reset the device but then it comes right back on solid.
that is from a scope 80mv pk to pk ripple.
Digging deeper into circuitry I see that W5500 does not have RX LED, it only has ACT LED and LINK LED. Thus my knowledge does not apply here and I can not qualify if for W5500 ACT LED turned on means lock-up or RX storm.
When you do it, how ACT LED looks like? Does it turn on steady (or almost steady), or blinks (e.g. 2 cycles per second)?
It will stay on after reset pin toggle or a software reset. I can also disconnect the network cable plug it back in. The link light will come on with the ACT LED on solid. The only way to clear it is a complete power cycle.
Shouldnāt be a RX storm I can have only the device connected to a switch and disconnect the switch from the network and there will not be a change.
It is weird. The device will respond to some traffic in this state but not all of it and it is very random as to what or when it will respond.
Seems like W5100 has ACT LED functioning like combination of RX and TX activity LEDs.
This means that PHY actually sees the link loss and cable disconnect.
In my case there was no one, but chip was thinking it receives something dues to issues with PHY. I foun dout that I have used too high temp when soldering the chips. Only chip replacement has helped, soldering manually at 305 C.
Are these off the shelf board you manually assembled them?
How many boards did you try?
These are WIZ850io modules Rev 1.0 made by Wiznet. It does happen on multiple boards. This is a preproduction run which we have been field testing but this particular problem will keep us from going to production using these boards unless I can figure it out. I chose these because they were easy to use and the software library that Wiznet has on gethub works pretty well.
You have genuine WIZnet devices, several of them. They all behave weirdly like you describe - after some time of operation it turns ACT LED on, and communication of hindered. When you perform hardware or software reset ACT LED turns off during reset, and then turns on steady again (right?). If you disconnect cable ACT LED turns off, and when you reconnect it again comes lit. If you power cycle the W5500 then situation is remedied (does it also mean you power cycle the controller driving the W5500?).
I do not believe you have faulty boards. There must be something else. The cause might be outside of the board - from network side or from its SPI side, or may be inside the board.
You have checked power with scope, and ensured that power, at any given nanosecond, is within specification. You reset W5500 pulling reset pin low for 500 ms (half of the second). You have checked that boards work with different switches, and board initially work and then ālock upā.
Now it is time to check SPI side programming.
You must wait for some time (1 ms, per datasheet) after you bring reset inactive before configuring W5500. You must not start programming immediately after RST goes high.
You must ensure that MCU does not continuously send commands to the W5500 like SEND or RECV - these actions will cause LEDs blinking or being lit. Simple test - when ālock upā happens deactivate SPI bus (e.g. by pulling its connector out, but preserving grounding).
I pull the reset pin low for 500ms then set it high then wait for almost a second.
Then for a sanity check I check the ID of the device.
Then configure xmit and recv buffers then device config mac, ip, mask and such. Then go on and attempt to connect to the server application, and open a UDP socket.
I though about the possibility of hitting the SPI port to hard or continuously but I can stop the port and processing with the CPU debugger. when this occurs I can break the processor so nothing is going on and watch the SPI bus stop.
It is strange to me that with both a software and hardware reset the device still comes up in this mode. It does return the correct ID and responds to the SPI communications just fine. It will even connect to the server just very intermittently.
There really isnāt that much traffic being sent a status message of 97 bytes every 30 seconds then IO messages of 128 bytes as they occur hours apart or a few seconds apart depending on what the device is doing.
I wonāt rule out something from the outside network but trying to find information on the device has been a bit tough. Are there know packets that can put the W5500 into a wierd state?
Good. Can you also check that after reset chip has āblankā registers? For example, source IP address is reset to 0.
So you use UDP, not TCPā¦ Put PC in bridge mode in between of the W5500 and another device so that Wireshark installed on it capture everything on the wire. I am interested in seeing what is going on the network when W5500 enters this state. By the way, nothing logged will not mean thereās nothing in there. There could still be invalid packets travelling being discarded.
It is not about the speed (if you are within spec of course). It is about performing wrong things to the W5500 (like sending some commands to the chip at unexpected times).
So do you confirm that when you stop SPI with debugger W5500 still has ACT LED lit?
This is not strange, this is close to impossible
Do you do reset properly? Right pin is being toggled? As I said before it may happen only in case thereās some activity from the outside: either MCU forces W5500 doing something, or thereās something in the network causing chip thinking it captures frames, or must respond to some incoming frames (e.g. ARP requests).
I will check the registers the next time I get it into this state. It isnāt frequent and tough to catch.
I have a TCP connection and a UDP socket going. UDP is rarely used. 99% of time it is TCP.
Yes when I stop SPI or the main CPU the ACT LED will stay on solid.
The Reset Pin is the pin being toggled. When the device getās in this state I can also reset the entire board with my debugger. The CPU and device get reset at the same time. download a new image and start debugging. It will stay in this state until a complete power cycle.
MAC address: 00:50:C2:63:B3:3C I have verified that it is not duplicated on our network.
Alright finally got another one into this weird mode. Here is a Register dump of one that is working correctly and one that has the ACT LED on all the time. they are labeled in the txt file. The differences are due to 2 different boards so 2 MACS and sets of IPs. We do see a difference in the SNIR (socket reg 0x003) register but it deals with the reserved bits so I have no idea what they are doing.
We did notice that the first attempt on Socket 0 to connect TCP failed but makes it on the second attempt.
Any other ideas we can try. So far these devices work great when they work but I donāt think I can spend much more time chasing this weirdness before I have to try another route.
Would it be possible to set to āAll capable, Auto-negotiation enabledā? I do not know how hardware negotiation works here, but given our symptoms may it be that link goes into different mode, but as W5500 PHY is forced it starts behaving weirdly?
Also note in datahseet:
If user wants to re-configure with PMDC[2:0], it should reset PHY by setting the RST bit to ā0ā after the user configures this bit as ā1ā and OPMDC[2:0] .
Thus according to it to make all-capable negotiation enable write 0x78 to PHYCFGR twice when configuring the chip (first time - setting config bits, second time - resetting the PHY). At least this is how I see it. If PMODE pins are connected to Vcc then you can just leave the reg alone, not touching it during initialization.
Iāll switch it back. But I had forced it to this mode due to an issue we had with a switch not playing nice with Auto-negotiotion. We will see what happens.
Well with Auto-negotiation back on we did manage to get it back in to the activity LED back on solid. This one really has me stumped. We think it may be tied to an unexpected hardware disconnect. say a switch getting power cycled or even unplugging the network cable during a transmit. Which would normally be OK. We can detect that and possibly reset the device if necessary but when the device is stuck in this mode it take a complete power cycle to bring it back to normal.
Does WIZnet monitor these threads and could they comment?
@midnightcow can you please advise? Any idea on the action plan to troubleshoot further to find out the cause of the issue?
@Lon_Hemmen probably good idea to play around with Wireshark seeing what is going on in the wire. For the clean test you must put the Wireshark device in between of W5500 and switch. Let me know if you need more information on how to do it.
