Problem during initialization

Question

Hi We designed a device which uses a W5500 for its network capabilities (basically it’s a very easy protocol which is transported via TCP). The communication and protocol usually work flawlessly, even for days or weeks with the exception of one moment - the startup. In some cases - it’s unreproducible at the moment - after power is applied to the device, the W5500 cannot be pinged. The LINK LED comes up as expected and the ACT LED shows some activity which could be related to the ping but the host (the computer which pings the W5500) doesn’t get a response. It shows that the interface is up and running, but no response. What I do during startup is: Bring RESET line low for 5ms Bring RESET line high, wait for 5ms Execute a software reset through ctlwizchip Setup MAC and IP, then wait a little (100ms) Usually from now on, the device will be accessible through the network interface except for some rare cases where it simply appears not to respond. Now I was wondering if there was any register I could read to determine if a real connection could be made or if there has been some issue. If I read the network info after setup, it is correct in all cases, even if I cannot ping the IC. I have a feeling that this is somehow related through capacitors being charged/uncharged during startup. The power supply has a low ripple. The reset of the IC is triggered after the mein microcontroller has come out of POR (and this is only after the power supply has stabilized above 3.16V at which time it already is at 3.3V). So I see no direct problem with the reset sequence. Any idea what I could look at?

Eugeny · Answer

somnatic: We designed a device which uses a W5500 for its network capabilities Do you have only one device, or several behaving the same way? somnatic: The LINK LED comes up as expected and the ACT LED shows some activity From my experience ACT LED is being flashed if there’s any activity on the network, not just an activity for the chip’s sockets. Anyway, the fact that LED flashes shows that PHY works and W5500’s network capture part also functional. somnatic: but the host (the computer which pings the W5500) doesn’t get a response I think it may be a good idea to use Wireshark to see what is going on between W5500 and the host, if there’re any packets sent by W5500 (e.g. maybe invalid ones or targeted for another network node). The best you put host with Wireshark running between W5500 and router (e.g. configuring Windows or Linux machine as bridge) so that you see activity from the “first hands” (without any filtering at the router side). somnatic: Setup MAC and IP, then wait a little (100ms) You also need to set IP mask. What MAC address you set? somnatic: If I read the network info after setup, it is correct in all cases, even if I cannot ping the IC. This means that MCU side of W5500 also functions properly. somnatic: I have a feeling that this is somehow related through capacitors being charged/uncharged during startup. Can you share circuit diagram, including MCU side? somnatic: Execute a software reset through ctlwizchip I am looking into the sources related to ctlwizchip, and see it invokes wizchip_sw_reset. 291 void wizchip_sw_reset(void) 292 { 293 uint8_t gw[4], sn[4], sip[4]; 294 uint8_t mac[6]; 295 getSHAR(mac); 296 getGAR(gw); getSUBR(sn); getSIPR(sip); 297 setMR(MR_RST); 298 getMR(); // for delay 299 setSHAR(mac); 300 setGAR(gw); 301 setSUBR(sn); 302 setSIPR(sip); 303 } I am astonished to see how it handles end of software reset. It just introduces delay using getMR(), hoping that chip finishes its software reset during its execution. That should…

Eugeny · Answer

somnatic: no matter if I perform the software reset or not One more thing then - use scope to prove that you comply to reset timing (5 ms low then 5 ms high as you say, see 5.5.1 in datasheet). The reason is your MCU not starting programming W5500 before it is ready, that’s why software reset, after power on, with checking MR_RST flag to turn off is a good idea in general.

somnatic · Answer

Eugeny, I tried some of your ideas: I checked the RESET lines using a scope and the reset sequence itself looks fine (power is stable long before the reset) and the reset is held low the expected 10ms, then goes high for a duration for > 10m and after that I get the ‘executing code now’ signal I setup through a gpio (I set the reset during to 10ms just to be sure). I edited the reset function (while), yet this didn’t change anything. BUT The idea of trying to get some information using Wireshark was a good one. I didn’t mention that except from the main TCP communications the device uses UDP packets to announce itself to whoever is listening on the network (broadcast). Within this broadcast, it also explicitly specifies its IP settings. When looking at those, I could determine that those were set to 0.0.0.0 for IP, Netmask, Gateway; yet, DNS was set correctly. Further debugging showed that whenever the values were set in such way, it couldn’t be pinged (I do a write and then a readback but no explicit checking as I assumed that this works). That makes sense, pinging was impossible, the UDP broadcast worked as it doesn’t really require a valid source address. I then added a 100ms delay before calling ctlnetwork (the call where I setup IP, …). Using this approach, I wasn’t able to reporoduce the problem, yet this seems like a bad solution to me. I reduced it to 10ms and the problem re-appeared (only very seldom, but it did). I have now added a while loop to continuously set the ip address (and also state the number of tries) and am currently trying to reproduce the behaviour or to get a readout of more than 1. Now the main question: Can anyone give me an indication why a delay of 100ms could be of use before ctlnetwork? Does the device perform any initialization; Why would IP, SN, GW invalid but DNS ok?

Eugeny · Answer

somnatic: Can anyone give me an indication why a delay of 100ms could be of use before ctlnetwork? I did not run in such problems most probably for simple reason - never started initialization just after power up. But I had similar issue with Altera FPGAs, when one of its IP blocks did not function properly just after power up, and their support and engineering was unable to answer what to do to make it operational so that I can start configuring it just after power on. The workaround was doing some actions several times, and wait some time, which I was also uncomfortable with, however it seemed to work. You case may be the same. If you find 100 ms delay working, and you really do not need to initialize and use W5500 just after power up, stick to it until you find the good solution. For example, if I would be designing W5500, I would still have bit 7 of the MR set during its hard initialization after hardware reset or power up, e.g. code would look this way: ... [initialization code] while(getMR() & MR_RST); // ensure hardware reset finished setMR(MR_RST); // perform software reset while(getMR() & MR_RST); // and wait until software reset finishes ... [W5500 setup code] I would not use ctlnetwork procedure at all because it performs wrong and unneeded tasks for the power up/initial configuration moment - reads SHAR, GAR, SUBR and SIPR when it is not needed. Probably doing it while chip is not ready yet makes it crazy. somnatic: Why would IP, SN, GW invalid but DNS ok? DNS information is NOT a part of chip configuration, and will not affect chip’s functionality. It is needed to perform DNS request using UDP socket type.

somnatic · Answer

Hi Eugeny Regarding DNS you’re right - it’s also the only register which is not written during wizchip_sw_reset. I have now changed the code to what you’re suggesting, let’s see how it turns out. In the meanwhile, I was able to catch a single happening where it couldn’t write the registers. It took the controller 647 tries (no wait time in between) until it was successful. I’ll have to check which time duration we’re talking about here. I then turned off power, and turned it back on and the device was able to write the data on the first try again (as is the usual case). It would be nice if someone from Wiznet could comment this issue. Specifying a reset duration of 1ms which sometimes works but sometimes doesn’t is just not right.

somnatic · Answer

Alright; apparently your code didn’t really help - the issue just appeared again; this is time I measured the duration and it was around 18ms. Any info what that could be?