WIZnet Developer Forum

Problem during initialization


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?

Do you have only one device, or several behaving the same way?

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.

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).

You also need to set IP mask. What MAC address you set?

This means that MCU side of W5500 also functions properly.

Can you share circuit diagram, including MCU side?

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 not be the right thing to do. The right way would be reading MR until its MR_RST bit is reset, in other words

  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    while(getMR() & MR_RST); // loop until bit 7 of MR register becomes 0
  299    setSHAR(mac);
  300    setGAR(gw);
  301    setSUBR(sn);
  302    setSIPR(sip);
  303 }

Please modify this routines in your project and see if it helps.

Eugeny, thanks for replying, I’ll try to post the schematics tomorrow when I have access to them.

As for your questions/suggestions:

  • It’s probably all devices (the first batch was 15 pcs) which issue this behaviour, yet I only tested 2 and both issue this behaviour
  • Wireshark is a great idea, I’ll certainly to that
  • I set all of them: IP, Netmask, Gateway and DNS (although the latter two are not needed). The MAC address is taken from a Microchip EEPROM which comes with a preprogrammed unique MAC address (don’t know the exact type right now). During startup, I read that MAC address and program it to the W5500; so the MAC should be globally unique and always the same; NetInfo shows the correct MAC address as well
  • Circuit Diagram: As soon as I have access to it (probably tomorrow)
  • ctlwizchip: Yes, that’s what I found, I’ll try your suggestion tomorrow - thanks; yet, what I think is that it works the way it is, because the behaviour is the same, no matter if I perform the software reset or not. According to some threads here, the hardware reset also resets all of the software registers

Thanks for your suggestions so far - I’ll try to come up with schematics and maybe more news tomorrow.

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.

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.


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 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?

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.

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.

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.

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?

Copyright © 2017 WIZnet Co., Ltd. All Rights Reserved.