W5500-Unable to write to Destination Port Address

Question

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. Config_Message860×177 4.62 KB SnipImage1054×771 132 KB

Eugeny · Answer

Seveni1423: registers they do not change What state socket is in when you perform these operations? Seveni1423: I’ve tried my code on various development boards from seedstudio and other vendors and the code works. Boards with W5500 chip? Seveni1423: I tried configuring these and then opening the socket and was not able to read them back. Can you explain in more detail? Are you able to read value of VERSIONR register?

Eugeny · Answer

You said: Seveni1423: anytime i try to write to destination hardware address, destination IP address, or destination port address registers they do not change. and then Seveni1423: I’ve tried my code on various development boards from seedstudio and other vendors and the code works. and then Seveni1423: the boards have the W5500 chip. 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?

Seveni1423 · Answer

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.

Seveni1423 · Answer

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.

Eugeny · Answer

Seveni1423: 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. 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.

Seveni1423 · Answer

Tried that. Did not change outcome.

Eugeny · Answer

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. Seveni1423: I’ve uploaded how i am handling the reset message. I have a ~1 second delay between reset and sending new messages. This is incorrect. You must wait until MR[7] clears, not for the specific time to expire.

7taras · Answer

Hi! Unfortunately, I’ve got same problem when I try to write destination MAC and IP addresses and port (Sn_DHAR, Sn_DIPR, Sn_DPort). Other registers being read and write well, but Sn_DHAR, Sn_DIPR, Sn_DPort are default always, any case. I use my own design PCB with W5500 chip, based on STM32F103RB, and own code (I don’t use any library like ioLibrary_Driver). VERSIONR = 0x04. Maybe exist the secret for writting Sn_DHAR, Sn_DIPR, Sn_DPort?