How long does W5500 (static IP etc) take to be really ready??

Hi all, 2 questions please:
this is for a remote, battery powered burst mode (each 5 minutes) station.

Q1)How long does W5500 take to be really ready after a (reset pin) hardware reset?
I read several postigs about this but they diverted into DNS and whatnot.
We have static MAC, IP, DNS, and are talking to another unit with static IP, so no DNS lookups or so.
It says PLOCK (PLL Lock) - 1 ms, but how long do we need to wait for W5500 to be able to actually be programmed with said static info?
Our code:

void resetEthernet(){ //resets the ethernet shield. Delays incorporated! Takes about ?? seconds.
  Serial.print("Resetting ethernet card..."); // texts are just for test, will be removed in production
  digitalWrite(PIN_ETH_RESET, ETH_RESET); // reset W5500
  delay(10); // 1ms needed per manual
  digitalWrite(PIN_ETH_RESET, ETH_NORESET); // turn off reset, let W5500 boot up
  delay(2000); // how long does W5500 take to be really ready for what comes next line??
  Ethernet.begin(mac, ip, dnsServer, gateway, subnet); // Eth must be initialized after each power up/reset
  delay(1000); // this delay relates to the Arduino Ethernet library
  W5100.setRetransmissionTime(0x07D0);  // reduce wait
  W5100.setRetransmissionCount(4);
  Serial.println("Done.");
}

Q2) How long does auto negotiation (10/100, full/half) take?
We need to “wake up” as fast as possible, but also save power.
Right now the W5500 is set to 10M Link (75mA) to avoid the 100M Link (128mA) .
I would love to set it to “Un-Link Auto-negotiation mode” (65mA), which saves another 10mA and limit the other side to 10M, as to avoid 100M Link (128mA), but don’t know how much time we’ll lose for the auto negoatiation.

Thanks!

Are you doing HFT?

The code is executed by the MCU, not W5500. Ask MCU how long it will execute the code under consideration.

No one is going to answer this question definitely because the process will also depend on the remote node. You need to perform benchmarking and close consideration of the negotiation process with this remote host.

Thank you for your reply.
Q1) If High-frequency trading then no, it’s a weather station.
What I meant with ready is to accept data written to its registers and processing them.
Just having the PLL lock after a msec does not neccessary mean the underlying circuit/registers are ready for programming?
Or does it really mean that after 1msec I can bombard the W5500 with MAC, IP data?

Q2) The other side is a Ubiquiti NSM5, it auto negotiates with a PC in less than a msec. Is W5500 in that range or does it take a second or so?

:slight_smile:
There’s a strict procedure on bringing the W5x00 up. It must be reset in hardware, it could be (should be) reset by software, this software reset must be waited for, and then you can set up registers using SPI and start working. First you can see in datasheet, last depends on speed of the bus. Exact value for the second is not known for me, there may be something in datasheet, but I guess you can measure yourself and more or less rely on the measured data. But you must ensure all the hardware, including the crystal, operates properly.

For the second question you must identify yourself and take responsibility for it. If it is your product, then it is up to you what endpoint device to use and how to use it. To speed up a process you may set remote port and W5500 into specific configuration to eliminate any negotiation. But again, it all must be tested beforehand. While you can find required info in specifications, you are interested in extreme case with minimal delays. Also note that higher frequencies lead to higher power consumption, thus you may just perform useless work - and there must be a kind of balance between them, and it may not be in the place you are currently searching in - maybe you’d better, for example, select specific speed for the programming and using W5500, transfer data, and power the W5500 down to save power. All depends on your real needs and requirements/specifications for the whole solution.

Q1) Great, thanks for confirming that there is a procedure, I didn’t know that.
I couldn’t find it, that’s why I turned to this forum and thankfully you stepped in and help me.
Where is that procedure?
I did check the datasheet, but couldn’t fid anything about any procedure you are mentioning.
Please tell me what page of the datasheet you are referring to.
I read it up and down.
Here is what I got from Wiznet:
https://docs.wiznet.io/Product/iEthernet/W5500/datasheet
or the datasheet itself:
https://docs.wiznet.io/img/products/w5500/W5500_ds_v110e.pdf
Thank you in advance.

It is simple:

  1. perform hardware reset per spec
  2. perform software reset and wait until reset bit clears
  3. load required common registers - ip address, mask, gateway - you’ll get what you need from register descriptions.
  4. set up a socket using its registers.
    5.ensure W5500 has connection to the network
    6 you are ready to make connection or receive connection

#5 is most variable requiring experimenting. For socket operation flows look into the W5100 datasheet, chapter 5.

Simple for you for sure, but not for me, stuck since days for this.
I can do

  • perform hardware reset per spec
  • perform software reset
  • load required common registers - ip address, mask, gateway
  • set up a socket using its registers.
    But don’t know how to
  • wait until reset bit clears

I kept searching the internet for that, results pointed mostly to these wiz forums, with no real actionable solution, ever.
It is amazing HOW MANY people like me got stuck with exactly this issue of WHEN the W5500 is ready to perform?
I read many excuses and diversions about “the other” side of the W5000, be it the SPI speeds used or the response of switches etc.

But WHY not focus and answer what Wiznet should know:
How much (internal propagation) time does it take from one task (like reset) to respond to the next task (programming the registers).
I mean these are internal state machines after all??
Which have NOTHING to do with how fast SPI is or whatnot.
Those SPI internals probably are not even ready during that period, until AFTER the reset phase.

I truly wonder if Wiznet doesn’t care anymore, they should really address this issue or point to actual code resolving this.
One of the main reasons to use these state machines was to be fast and easy.
But it seems these chips are neither fast nor easy.

Anyhow, sorry about this rant against Wiznet, but I see nearly no response from Wiznet for many years anymore.

It’s mostly you, who kindly fills this void.
I hope you get paid by them for your invaluable help!
Never thought I would need to dig this deep in bitwise monitoring/manipulation for such a simple matter.
I don’t know how to do that, and am thinking of further issues like how to escape that loop if the flag is never set (W5500 not powered or so).

Dug in wiznets io libraries, could find references to CW_GET_PHYCONF and CW_GET_PHYSTATUS but don’t know if those are the right flags to check?

I am sure you came across some actual code regarding this flag in the PHYCONF register.
Could you please point us to such a routine, preferrably in C?
Thank you!
Addendum: To save power, we keep W5500 completely turned off.
When we need to send data, Reset is activated, then power applied, then, after 100ms, Reset is released.
However, the W5500 is by far not ready to be programmed (IP, MAC etc) at that stage.

How do you know?

Let’s restart. You apply power, wait for some time (let’s say, same as hardware reset), then perform hardware reset using reset pin per documentation, then read VERSIONR register to identify if chip is there, then perform software reset writing 0x80 to MR and waiting it to clear, then write own mac address, IP address, mask, gateway, timeout values (if needed) then set up socket with its MR and check for status SR to change to appropriate value, then perform connecting using CR and waiting until CR clears and then for SR changes to see the result of the operation. After done you close the socket using CR. The whole flow is in W5100 datasheet, chapter 5.
The socket operation timing in TCP mode can’t be definitely known because it depends on remote device (UDP is send and forget, unless it involves ARP). For this you may (as you said before) try to define all the operating modes of all nodes (W5500 and switch) to minimize time spend on negotiations. For W5500 you can do it using hardware (config pins) or software (using PHYCFGR reg).

I now think that we focus on different datasheets, I have linked and am talking the whole time about W5500 and you are referring to the W5100 now.
There is no “whole flow is in W5100 datasheet, chapter 5” in chapter 5 of W5500 I had linked above.
We were told to use the W5500 for this project, the guy said the W5500 is more stable (but how much?).

Here is what we do:

  1. activate W5500 reset
  2. apply power to W5500
  3. wait 10ms
  4. release reset
  5. wait 10ms
  6. issue a soft reset ← not anymore
  7. wait 10ms ← not anymore
  8. Ethernet.init (pin53)
  9. Ethernet.begin(mac, ip, dnsServer, gateway, subnet);
  10. wait 10ms (to 300ms)
  11. server.begin();
  12. wait 2200ms (!!!)
  13. Ethernet.linkStatus()
  14. start sending if “LinkON”

We took out
6) issue a soft reset
7) wait 10ms
since it made absolutely no difference whatsoever.

From 8) on it functions sometimes, but always if we wait at least ca 300ms at 10)

The static wait of 12) of 2200ms, and uncertainty of 10) wait for 10 to 300ms is what bothers me.
I would love to use the flag you so often mention, but that is a bit operation which I don’t know how to check in Arduino C
I found at least 20 of your recommendations to check that flag, but you never posted an actual code of how to in C.
We use
Ethernet.linkStatus() to find out if the W5500 is really operational.
But that sometimes results in no operation (“Unknown”) as mentioned above.

“How do you know?” we try to read back the data, monitor SPI signals, and set flags along the test routine.
We tried 3 different boards, 2 of the smaller W5500 and Arduino’s Ethernet 2 shield (also W5500).
And two different Mega board.
The whole setup is powered by a 12V DC/DC converter and I personally placed a few ceramic 22uf-100uf at the actual W5500 board and the 12V/5V dc converter and the 3.3V converter.
I personally checked the voltages during transitions etc.

My colleague is now looking at another option, seems this all was a total waste of your and our time.

I program in assembler and do not use any libraries. I operate W5500 registers.
Every routine must return the status/error code, you must capture it and to identify the issues.
I may guess what your pseudocode performs in general. But why it is called “server” if you send data?

Gives an idea that this “delay” is needed for “begin”. What this “begin” is doing? Where does it fail? Return error codes? Read MR register in loop just after you release reset and see what it outputs.

What did you exactly do in these steps?

There must be routines for direct access to registers in the library you use. But I would expect libraries to do the right things by default.

And where it fails? How do you know exactly?

Suspect it is not a board’s problem.

Hey all,
we decided to abandon this and use a Microchip device instead.
They are way more professional and responsive, have beautiful libraries and current and working examples.
My colleague was always referring to wiznet as witznet, always thought he cannot pronounce it correctly (he’s German). So he finally told us that ‘witz’ means joke in German.
Very fitting.
To those who end up here by google search, don’t bother, use Microchip (or others) instead.