W5500-Unable to write to Destination Port Address

Hello,
I am unable to write to any of the socket destination ports. I can update the Socket Port registers but anytime i try to write to destination hardware address, destination IP address, or destination port address registers they do not change.
I’ve tried my code on various development boards from seedstudio and other vendors and the code works.
I tried configuring these and then opening the socket and was not able to read them back.


Respond_Message

What state socket is in when you perform these operations?

Boards with W5500 chip?

Can you explain in more detail?

Are you able to read value of VERSIONR register?

the W5500 is reset before i write to it. The socket is closed and in a neutral state…SR=0.
the boards have the W5500 chip.
Before I write to the registers I do put the socket into UDP mode.
I’ve read forums that the Destination IP addresses and the Destination ports don’t update unless you open the socket.
I am able to read the VersionR register and get the 0x04 value everytime.
The pictures above are a capture of the actual SPI messages I’m sending. Top is response from W5500 and bottom is what I’m sending it.

You said:

and then

and then

Did I understand properly that you have custom board with W5500 chip on it, and after writing data to DIPR and DHAR and then reading them back values do not match, but when you use another board, also based on W5500, withe exactly the same code you write specific values and read them back?

In other words, exactly same code produces different results on different boards?

you are correct in your assessment with one correction. It seems that DIPR, DHAR, DPORT do not actually update when I write to them.
But yes…same code…different results on the boards. Hence the attached schematic and the SPI messages sampled with a logic probe.

If the difference is only the board you run code on, then problem, logically, is the board or its components. But I doubt this, because you said you can read VERNSIONR register back as 0x04, and your pics show 0x01 0x02 0x03 during command execution. Therefore SPI must be functional. If SPI is functional, then it does not matter what command - read or write - goes through it, chip must accept and perform it.

Thus either W5500 is not performing properly, or there’s something else, some difference between the boards, in W5500 handling that we do not know about.

How chip hardware reset is handled? Same way on all boards?

RESET_MESSAGE
I’ve uploaded how i am handling the reset message.
I have a ~1 second delay between reset and sending new messages.
Same way on all boards.
I can do a hardware reset as well if necessary. the RSTn pin is pulled high by the microcontroller on startup with a 100mS wait between the pulling high and the software reset command sent. This is 100x the amount of time for pll lock in the datasheet.
What is weird is that this issue is across both of my custom boards. Boards bought by a third party do not have the issue. Is it possible I got a bad batch of W5500s?
Any troubleshooting suggestions? I’ve tried VDM and FDM when sending messages and no changes in results.
My microcontroller is running at 16Mhz so the bit period so the CS_high time is well within the normal timeframe. I don’t have a probe for CS on my board so I can’t be specific.

Set it low when microcontroller starts, wait for 500 ms, set it high, and then proceed as you do after 100 ms. I do not know if it will help, but we must try at least.

Tried that. Did not change outcome.

I still have no useful ideas to pursue. It looks like software is the same, only W5500 hardware differs (or processor/microcontroller hardware also differs?). You say you can write to other registers and read their updated values back. But not specific registers. I would suggest you try to update those ‘failing’ registers in wrong time (socket state), but you say same algorithm works on other W5500 boards.

In these conditions, when you have no idea where and what to look for, it probably makes sense performing full logging of SPI operation on working and ‘failing’ boards (all 4 signals) and compare the operations and timing to get at least some idea on the differences.

This is incorrect. You must wait until MR[7] clears, not for the specific time to expire.