W5500 get version returns 0x01020304. Is that correct?

Is it normal to receive the additional bytes (0x010203) from the W5500 before the requested data? In this case the version (0x04).

In another post I noticed someone else receiving similar output from the W5500.

Attached is the scope trace. D7 - clock, D6 - select, D5 - MISO (0x01020304), D4 - MOSI (0x00390000).

You command W5500 with 0x00 0x39 0x00 0x00, requesting it giving you contents of VERSIONR register. It is not documented in the datasheet, but I bet that:

  • data on the MISO line is not defined until proper MOSI request sequence is complete, thus reading MISO the way you do generally is not supported;
  • however, for debugging/troubleshooting purposes WIZnet decided to have its W5500 reply with command byte position as command arrives (aka command phase - expecting last bit of the byte on next rising edge of the clock), thus 0x01 means byte 1 ends, 0x02 means byte 2 ends, 0x03 means byte 3 ends and application may expect next byte to be the meaningful data.
1 Like

Thanks again Eugeny.

It seems that every response from the Wiznet 5500, for the commands tried (so far), always include the 0x010203 prior to the actual data. I suspect your correct about the meaning of the 0x010203 prefix. It makes sense.

data on the MISO line is not defined until proper MOSI request sequence is complete, thus reading MISO the way you do generally is not supported;

What do you mean here by, “generally not supported?” What is the supported method to read the MISO line?

Kindly,
Graham

As this 0x010203 is not documented, manufacturer does not guarantee that this functionality will be present in future versions of the chip. If, for some reason, this functionality will get removed, support personnel will not accept service incidents based on this missing undocumented feature.

The supported method and time of valid data are described in the datasheet.

Ok I see what you mean.

Basically, don’t count on the 0x010203 sequence being present since it’s not documented. Fortunately, my code simply ignores that sequence.

Though the 0x010203 does enter the master’s receive fifo buffer so they must be read in order to get to the requested data. There doesn’t seem to be a method to prevent the MISO prefix data once the CS is driven low.

Thanks again,
Graham

1 Like

So just read these 3 bytes (24 bits) and discard them.

Yeah, that what the code does.