W830MJ socket status 0x10

Question

I am using the WIZ830MJ module, which uses a W5300. Most of the time I am listening for a TCP/IP connection and am in the LISTEN state. When I need to connect to a server I first make sure no connection is up (still in LISTEN state), then I do a close, followed by a connect to establish an outgoing TCP/IP connection. I then wait for the socket status register to indicate either 0x17 (SOCK_ESTABLISHED) to indicate the connection has been established, or 0x00 (SOCK_CLOSED) to indicate the connection could not be established (refused or timed out, for example). Most of the time this works very well. However, every once in a while my system locks up and I cannot communicate with it over the ethernet port. This happens rarely, and it has taken me a while to figure out what is going on. It turns out that when my system locks up the socket status register (S0_SSR1 at address 0x209) has the value 0x10, and it stays that way forever until I power cycle my system. What is socket status 0x10? This is not documented in the W5300 datasheet. What does it mean? How does it get into this state? What should I do to recover from this state?

becky · Answer

Hello, image901×770 245 KB 0x10 means SOCK_SYNSENT state. After sending a SYN packet from the W830MJ, it is assumed to be in the SYNSENT state because the server does not give RST packet or SYNACK packet to the SYN.

becky · Answer

Hello, Or it could be the situation on the Errata Sheet below. See page 3 wiznet.io W5300_ET_V123E(1).pdf 419.80 KB

microaide · Answer

I don’t know where you got your information about socket status 0x10 being SOCK_SYNSENT, but that is wrong. On page 78 of the W5300 datasheet Version 1.3.3 (or page 75 of the W5300 datasheet Version 1.2.2) it clearly states that 0x15 is state SOCK_SYNSENT. The Errata sheet looks more promising, but I am still confused about why the Errata sheet should be talking about socket status register values of 0x10 and 0x11 when neither of these values is mentioned at all in the W5300 datasheet. So I looked at my driver code I use to control the W5300. My driver code was derived directly from the sample driver code provided by Wiznet. I looked at my close() function, and found that the fix suggested in the Errata sheet was already in my code. This is not surprising, since the code came from Wiznet. So, in spite of the Errata sheet fix already being in my code, my system is still locking up from time to time with a socket status register value unexpectedly stuck permanently at a value of 0x10. Where do I go from here? I am still stuck.

microaide · Answer

So what you are saying is that the Wiznet documentation is incomplete and inaccurate. I can believe that. But that still leaves me with a system with driver code that already has implemented the “fix” suggested in the errata sheet you referenced, but my system is still occasionally locking up with the socket status register stuck (apparently permanently) at 0x10. My question remains unanswered: Where do I go from here? What can I do to fix it?

microaide · Answer

You say “So we decided that we did not need to present 0x10 to the document.”, yet on pages 78-80 of the W5300 datasheet (version 1.3.3) Wiznet did chose to document the following “temporary status” states of the socket status register: 0x15 SOCK_SYNSENT, 0x16 SOCK_SYNRECV, 0x18 SOCK_FIN_WAIT, 0x1B SOCK_TIME_WAIT, 0x1D SOCK_LAST_ACK, 0x01 SOCK_ARP. I cannot imagine why you would fail to document 0x10. You say “Under normal circumstances, a timeout occurs because no response is received from the server and becomes a closed state . Or it receives a SYN ACK from the server and becomes an established state.” Yes, that is what I expect. I call connect(), then wait for socket status to change to either SOCK_ESTABLISHED (indicating the connection was successful), or SOCK_CLOSED (indicating the connection failed (was refused, or timed out). This is what I expect to happen, either connection established, or socket closed. Is this the correct way to handle a connection (call connect(), then wait for SOCK_ESTABLISHED or SOCK_CLOSED)? It seems to be what is documented. Yet sometimes I wait forever, getting neither SOCK_ESTABLISHED nor SOCK_CLOSED. Instead I see socket status 0x10 persisting forever. When this happens, my system is locked up and needs to be power-cycled. I would be happy to provide you with a wireshark capture of what happens when the W830MJ sends a SYN, but I have a problem doing that. Most of the time it works as expected, giving me SOCK_ESTABLISHED (or in rare cases SOCK_CLOSED if the server is not available). I have attempted to duplicate the socket status 0x10 problem in my lab, and after months of testing have seen the problem appear exactly one time. But that doesn’t mean this is not a serious problem. My customer has hundreds of these systems installed in the field operating on a live network, and failures are happening at a rate of many failures per week. It is not practical for me to do wireshark captures on all of the customer’s systems. Even if I…