--- title: "WIZ850io module activity LED always on." url: "https://maker.wiznet.io/forum/13215" markdown_url: "https://maker.wiznet.io/forum/13215/md" type: "Forum topic" category: "Ethernet Chips" author: "Lon Hemmen" created: "2019-02-21T17:49:53+09:00" last_activity: "2022-08-11T11:59:33+09:00" language: "en" views: 2586 replies: 33 source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)" --- # WIZ850io module activity LED always on. ## Question Asked by Lon Hemmen on 2019-02-21 in Ethernet Chips. 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. Any ideas were to start looking? ## Replies ### Reply 1 by Eugeny, 2019-02-21 W5500 thinks it receives something. Sounds like PHY issue. Lon_Hemmen: > It will stay on after a software reset or toggling the reset pin low for 500ms then back high. 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. ### Reply 2 by Lon Hemmen, 2019-02-21 (in reply to reply 1) 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. Power do the device is 3.33V to 3.38V ### Reply 3 by Eugeny, 2019-02-21 Lon_Hemmen: > I have tried 2 other network switches both from different manufacturers. Ok, good. I assume W5500 goes into this state for both? Lon_Hemmen: > It doesn’t happen often and I really have to push it to get it into this state. Push it? Can you please explain? Eugeny: > if ACT LED turn on steady or blinks like there’s something on the wire You did not answer this. Lon_Hemmen: > Power do the device is 3.33V to 3.38V This is average power level if you measure if with multimeter. You must take scope and see what is going on in there at microsecond scale. ### Reply 4 by Lon Hemmen, 2019-02-21 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. ### Reply 5 by Eugeny, 2019-02-21 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. Lon_Hemmen: > with pushing it I meant the amount of data that we are transmitting. 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)? ### Reply 6 by Lon Hemmen, 2019-02-21 stays on steady no blinking at all. 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. ### Reply 7 by Eugeny, 2019-02-22 Lon_Hemmen: > stays on steady no blinking at all. Seems like W5100 has ACT LED functioning like combination of RX and TX activity LEDs. Lon_Hemmen: > The link light will come on with the ACT LED on solid. This means that PHY actually sees the link loss and cable disconnect. Lon_Hemmen: > 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. 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. Lon_Hemmen: > 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. Are these off the shelf board you manually assembled them? How many boards did you try? ### Reply 8 by Lon Hemmen, 2019-02-22 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. ### Reply 9 by Eugeny, 2019-02-22 So let’s summarize. 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). ### Reply 10 by Lon Hemmen, 2019-02-22 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? ### Reply 11 by Eugeny, 2019-02-22 (in reply to reply 10) Lon_Hemmen: > I pull the reset pin low for 500ms then set it high then wait for almost a second. Good. Can you also check that after reset chip has “blank” registers? For example, source IP address is reset to 0. Lon_Hemmen: > open a UDP socket 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. Lon_Hemmen: > I though about the possibility of hitting the SPI port to hard or continuously 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). Lon_Hemmen: > when this occurs I can break the processor so nothing is going on and watch the SPI bus stop. So do you confirm that when you stop SPI with debugger W5500 still has ACT LED lit? Lon_Hemmen: > It is strange to me that with both a software and hardware reset the device still comes up in this mode. This is not strange, this is close to impossible ![:slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) 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). By the way, what MAC address do you use? ### Reply 12 by Lon Hemmen, 2019-02-22 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. ### Reply 13 by Lon Hemmen, 2019-02-28 A[w5500regdump.hex](https://maker.wiznet.io/forum/legacyFile.asp?path=b5LHJuGTm0j0NTsW7rxv0tUm8ai.hex) (9.1 KB) text file. 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. ### Reply 14 by Eugeny, 2019-03-01 (in reply to reply 13) Lon_Hemmen: > text file ``` PHYCFGR:DF ``` 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. ### Reply 15 by Lon Hemmen, 2019-03-01 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. ### Reply 16 by Lon Hemmen, 2019-03-01 (in reply to reply 15) 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? ### Reply 17 by Eugeny, 2019-03-01 [@midnightcow](https://maker.wiznet.io/u/midnightcow) can you please advise? Any idea on the action plan to troubleshoot further to find out the cause of the issue? [@Lon_Hemmen](https://maker.wiznet.io/u/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. ### Reply 18 by Lon Hemmen, 2019-03-01 working on getting a laptop setup for bridging. I don’t have a hub laying around to use won’t be ideal will have to bridge wired to wireless. ### Reply 19 by Eugeny, 2019-03-01 Lon_Hemmen: > working on getting a laptop setup for bridging. Whatever media will be at the other end. You will be able to capture packets on both physical segments. ### Reply 20 by Lon Hemmen, 2019-03-01 ok I’ve got a couple of captures. Device talking to the pc running wire shark through 2 network switches. Once the connection is lost in this case unplug the network cable we will see a tcp retransmission from the server, then when the cable is plugged back in and the act led goes solid we will begin to get TCP spurious retransmissions. It will continue with the spurious retransmissions even after we reset the device. Once we do a full power down and back up it will begin working again. otherwise I really don’t see anything strange in wireshark until we get it in this mode. [![Capture](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/2/2583afc37b6ddbee22c1706c3b893e4a08021867.jpeg) Capture1340×953 286 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/2/2583afc37b6ddbee22c1706c3b893e4a08021867.jpeg) ### Reply 21 by Eugeny, 2019-03-01 The screen shot does not list some packets (look at No.). The visible list should not cause ACT LED lit. Please dive into remaining packets, especially those appearing on the W5500 interface side. ### Reply 22 by Lon Hemmen, 2019-03-01 I filtered the traffic to only the device (10.10.10.191) and server (10.10.10.252) and I agree I don’t see anything that would keep the act LED on continuous. I have hooked the device into a switch with nothing else connected while it is in this state and the act LED will stay on. That is why this is so strange. BTW Eugeny than you for your time on this ![:slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) [![Capture2](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/7/71fbda530a3ac630db162f07a3841af19af3fdfc.jpeg) Capture21417×936 289 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/7/71fbda530a3ac630db162f07a3841af19af3fdfc.jpeg) ### Reply 23 by Eugeny, 2019-03-01 (in reply to reply 22) Lon_Hemmen: > BTW Eugeny than you for your time on this ![:slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) Thank you. I am out of constructive ideas so far, the only comes to mind is try change every module changeable (e.g. power supply with another type, processor with another board, cables etc) and blindly look at differences. I am inclined to think there’s something wrong with the modules (WIZnet will not like it!). I think modules are produced on the contract, thus even if WIZnet makes good chips they may be defected down the road - manufacturer of the board, then handling, then when using… The obvious thing is that as soon as you have several modules behaving the same way either we do something wrong to the module, or something wrong with the module. So summarizing: W5500 enters the mode when: - if it is connected to switch with no other devices connected to it, it flashes ACT LED, and there’s no traffic on the wire; - stopping SPI communication does not stop the flashing (thus it is not software doing something to the chip); - only power cycles cures. Hardware/software reset makes no difference. ### Reply 24 by Lon Hemmen, 2019-03-04 you Summary is correct except the ACT LED stays on solid not flashing. - if it is connected to switch with no other devices connected to it, ACT LED on SOLID, and there’s no traffic on the wire; - stopping SPI communication does not clear the ACT LED(thus it is not software doing something to the chip); - only power cycles cures. Hardware/software reset makes no difference. At this point I think we may have to look at a different solution. I haven’t been able to get a support reply. I hate to do since this was a perfect fit for what we were trying to do. Eugeny thank you for you help on this. ### Reply 25 by Lon Hemmen, 2019-03-06 well I haven’t given up quite yet. after reading through the forum I found this thread: [High temperature and high consumption](https://forum.wiznet.io/t/topic/3602) the state of the ACT LED isn’t mentioned but the W5500 was getting in to a funky state. I have modified teh WIZ850io to remove the ferrite bead between AGND and DGND and changed the damping resistors to 0 ohms. Now we haven’t been able to get the W5500 stuck in the funky state with the ACT LED on constantly. I am not going to call this fixed yet. We are going to stress the unit for a few days and see what happens. If this works we will just add the W5500 to our boards instead of the WIZ850io and a way to power cycle the device from the micro. Fingers crossed. ### Reply 26 by hafnerm, 2019-12-11 Hello forum, we are using the WIZ850io modules on our board since 2016 and have used some hundreds of them without problems. But with the last bunch of about 50 boards we have on many of them exactly the same wired behaviour of the WIZ850io module that was discussed in this thread. After a undetermined duration of normal function the WIZ850io stop working: - Activity LED and Link-LED are permanently on - No stable ethernet communication to host pc is possible - Ethernet communication traced with wireshark shows many retransmits If i disconnect the ethernet cable: - Activity LED and Link-LED are off If i reconnect the ethernet cable: - Activity LED and Link-LED are immediatly and permanently on Holding the reset pin low for many seconds: - Both LEDs are off After releasing the reset pin with cable connected: - Activity LED and Link-LED are immediatly and permanently on Only a power down/up can bring the WIZ850io module back to normal operation. Unfortunatly we do not know how we can reproduce this wired behaviour. It happend undetermined, and so we can not select good modules. Was there any change in hardware in 2019 to the WIZ850io module, because with the older modules we have not seen such as wired behaviour? ### Reply 27 by Eugeny, 2019-12-11 (in reply to reply 26) Are modules geniune? ![](https://avatars.discourse-cdn.com/v4/letter/h/e9bcb4/48.png) hafnerm: > After releasing the reset pin with cable connected: > > - Activity LED and Link-LED are immediatly and permanently on When cable is reconnected the round of negotiations must be performed (I guess unless you hardwired the W5500 to specific configuration through PMODE pins) , and if there was PHY error, it is usually cleared. In your case it is not, thus the problem can easily be outside of the W5500 (but can also be interoperability issue). Any changes in infrastructure (e.g. using new models of hubs/switches)? As test: - reset driving microcontroller, but not W5500. This way we will check how activities from MCU affect this behavior of W5500; - after this happens, plug another netowrk cable to the W5500, but with guaranteed no traffic (e.g. standalone hub with only one device - W5500 - connected to it). This way we check if the issue is caused by the storm in the wire. ### Reply 28 by hafnerm, 2019-12-12 - Yes, the parts are genuine. - No changes to the infrastructure, same type of netgear 100M ethernet switch used . - Holding our microcontroller in reset dosn’t change the behaviour of the WIZ850io module. If the WIZ850io module is in the wired state (both LEDs are permanently on) after some hours of normal working: – Holding our microcontroller in reset: → nothing change, both LEDs are premanently on – our MC is permanently in reset for the next steps. – Disconnect the ethernet cable: → both LEDs changing immediatly to permanently off – Reconnect the ethernet cable, with no other connections to the ethernet switch: –>both LEDs changing immediatly to permanently on – PowerDown/Up to the board and holding our MC in reset and no powercycle to the ethernet switch: –>WIZ850io module behaviour is returned to normal operation ### Reply 29 by Eugeny, 2019-12-12 What is the temperature of the chip? What is exact power supply voltage? Can you measure the current being consumed in normal and in this this faulty condition? Can you confirm that in this condition communication is possible, however unstable? Can you perform changes mentioned by [@Lon_Hemmen](https://maker.wiznet.io/u/lon_hemmen) in his last post - ferrite bead and damping resistors, or at least check that they are of correct value? In general - inspect the board with the magnifier and compare its components to the circuit diagram. ### Reply 30 by hafnerm, 2019-12-12 - Chip temperature: i don’t know, because it is not accessible. Ambiente temperature is about 30°C - Powersupply voltage is about 3.3V, and it must be > 3.15V, because our MC is running and we have a supervisor IC with a threshold level of 3.15V - No i can’t measure the current consumed by the WIZ850io, but it will not be the 700mA mentioned in the thread [High temperature and high consumption](https://forum.wiznet.io/t/topic/3602) , because our 3.3V linear voltage regulator can’t provide so much current. - No i can’t check and change the damping resistors and the ferrit bead, because the WIZ850io is soldered on our board and so the parts are not accessible for me I have the problem that i don’t have a test-setup where i can reproduce the failure, do some changes and check again. The WIZ850io modules are part of our testsystems that is running at our customers a few 100km away from me. And the ethernet failures are stopping the testsystems and this is not practicable for our customers. So for a workaround, we have changed the communication from ethernet to USB, because the motherboard for the WIZ850io has also a USB interface. I don’t understand why we have not seen such problems in the past. Our hardware has not changed, and also the environment has not changed. ### Reply 31 by Alireza, 2022-05-17 HI i have problem led always on could you tel me how can solvemy problem step by step? ### Reply 32 by Alireza, 2022-05-17 could you help me ? ### Reply 33 by Eugeny, 2022-08-11 (in reply to reply 32) Hope you solved your problem already. If not, you need to provide details on what setup you have, and you tries so far, and what software does with the chip. --- Source: https://maker.wiznet.io/forum/13215