W5500 TCP Client CONNECT problem


It sticks at SOCK_INIT state, it’s like if it never executes the CONNECT command. After a couple of seconds the timeout event is generated and it returns to SOCK_CLOSED state.[quote=“Eugeny, post:9, topic:964”]
I recommend you to try connecting to PC with Wireshark installed, and capture packet information when W5500 tries to connect to this PC, and see the packet exchange. You can also see the internal state transitions in the uart log window.
I’ve already done that but I don’t get any package from Wiz5500. In the following images, the first one shows the package interaction using wiz5500 as TCP client.

The second one shows the package interaction when Wiz5500 is configured as TCP server, which is completely functional.

This is the bascom code snippet i’m using to do this:

Dim server as byte : server = 0
Select Case socket_n(1)      
    Case SET_TCP_MODE :
        Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_mr , Sn_mr_tcp)    'Set TCP Mode Command'
    Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_port0 , &H13)        'Sets source port number high byte <port>=5000'
    Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_port1 , &H88)        'Sets source port number low byte  <port>=5000'
    Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_cr , Sn_cr_open)   'Excecutes OPEN command'
    socket_n(1) = SOCK_OPEN

Case SOCK_OPEN :                                                                          
    eth_read = Wiz5500_readvalue(W5500_S0_reg, W5500_ sn_sr)    'Is Channel Opened?'
    If eth_read = Sock_init Then                                'If server mode'
        If Server = 1  Then
            Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_cr , Sn_cr_listen)    'Excecutes LISTEN command'
            socket_n(1) = SOCK_LISTENING
        Else                                                                                                           'If client mode'
            'Server IP address'
            Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_dipr0 , 192)
            Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_dipr1 , 168)
            Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_dipr2 , 1)
            Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_dipr3 , 51)

            Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_dport0 , &H1B)    'Sets destination port number <port>=7000'
            Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_dport1 , &H58)

            Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_cr, Sn_cr_connect)    'Executes CONNECT command'
            socket_n(1) = HANDSHAKE
        End If
    End If

    eth_read = Wiz5500_readvalue(W5500_S0_reg, W5500_sn_sr)
    If eth_read = Sock_listen Then
        socket_n(1) = HANDSHAKE
    End If

‘-------- ESTABLISHMENT ---------’
Case HANDSHAKE: ‘Establishment’
eth_read = Wiz5500_readvalue(W5500_S0_reg, W5500_sn_sr)
If eth_read = Sock_established Then
socket_n(1) = HANDSHAKE_ACK
End If

eth_read = Wiz5500_readvalue(W5500_S0_reg, W5500_sn_ir)
value = eth_read AND Sn_ir_con
If value = Sn_ir_con Then
Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_ir , Sn_ir_con) ‘Clear connect flag’
socket_n(1) = RECEIVE_DATA
End If
End Select

Sorry for the tabulation, I couldn’t get it to be organized.
Thank you for your help.



I have a question about your first screenshot. Dst port is 0, right?
If the current server is open on port 7000, it may be necessary to verify that the 7000 is properly applied to the register.

And check your server’s firewall.
There is no problem if the module is a server, but when the module connects to the server as a client, it can be blocked by the server side firewall.


DIPR (destination IP address register) is located in S0_reg block, not in common register block.

Comment seems to be wrong, you set destination port.


Hi Kei,

Yes both the Dst Port and the Dst IP registers keep as 0 even if I write them with another values, some posts before Eugeny said that it is a normal behavior since these registers can only be read after getting the ESTABLISHED state but I’ve couldn’t find that specification for these registers in the datasheet. I’m ensuring that Wiz5500 is configured in TCP mode before setting the Dst port and IP regs as suggest the datasheet.

I had already ensured that the firewall is not blocking the connection using another laptop as TCP client to connect to my pc which was working as a server and it worked without any problem.


Thank you Eugeny I hadn’t noticed that mistake, unfortunately it doesn’t solve my problem it keeps sticking at the same state, getting the timeout event and showing nothing from Wiz5500 on the wireshark terminal. The only thing that have changed is that now Dst IP reg keeps as 0 even after writing another value on it just in the same way that happens with Dst port reg.


Perform the following already existing code

before you open the socket, in Case SET_TCP_MODE : block (checking for server being 0).
In Case SOCK_OPEN : block you just issue CONNECT command.


No, it is not the problem, in the real version I have some prints into conditionals in order to be aware whenever it reaches the condition, also I have put those instruction within an infinite loop, but the result is always the same, I can’t read the values written on Dst port and IP regs. I tried to read those regs after ESTABLISMENT state when W5500 is working as TCP server and I got my laptop IP and port so the read/write operations over those registers are working good too.


You should not do it, and it will not give you proper read until connection is established. It is this way by design, it is not a bug.

I am not sure what you mean, but you should NOT write anything to W5500 in infinite loop.

I ask you please set DIPR and DPORT values before you issue OPEN command. Currently you set DIPR and DPORT after you OPENing socket (and before you perform CONNECT command).


I’ve just did it but nothing changed :confused:.

Sorry I know I should not do such a thing but I’m a little bit desperate.


Hm… this is strange.

Let’s review everything again, thread is relatively long and code is kind of messy in it, so:

  1. you power device on (hardware reset), and then perform software reset writing bit 7 set to MR, and then wait until MR register clears to 0;
  2. you set up SIPR, SUBR, SHAR (common register block). I do not talk about interrupt registers as they are implementation dependent and should not affect socket initialization process (unless your application misuses it somehow);
  3. I never worked with no gateway configurations, I think you can leave GAR uninitialized;
  4. then you set S0_MR into value of 1. Also assume you set socket memory allocation properly so that socket is having TX and RX buffer space (Sn_RXBUF_SIZE and Sn_TXBUF_SIZE, or you leave them default);
  5. You preset DIPR, SPORT and DPORT (socket 0 registers);
  6. you issue OPEN command into S0_CR, and wait until this register clears to 0. SR should become 0x13 (or 0x00 if there’s socket open error);
  7. you issue CONNECT command; and wait until S0_CR clears. After this, in some time, SR becomes either 0x17 (connected/established), or something else. As I understand currently you have flow stuck at 0x13 at this point, right?

If it is the case and you are stuck at 0x13 after you issue CONNECT command, there’s some problem in there, because after 0x13 it should change to 0x14-0x15 (SOCK_SYNSENT) - 0x16 (SOCK_SYNRECV), and pending 0x13 means that chip is not able to even send SYN packet for some reason.

Please check your application to be compliant to my plan above, and let us know.



I think I’ve found the solution, it was nothing related with the steps I was performing but with a time constrain. It seems that it’s necessary to wait a minimum time of 800ms (for client mode) between the execution of OPEN and CONNECT commands, only in this way the Wiz5500 could reach the ESTABLISHED state and achieve de connection with server. I don’t know why is this but I found it while I was rewriting the code out the state machine fashion putting delays between all the steps, once it works I took the delays out one by one finding out that this one between OPEN and CONNECT commands was the only one which keeps the functionality.

Thank you so much for your help.
Best regards.


Your code was missing “you issue OPEN command into S0_CR, and wait until this register clears to 0”. It was performing Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_cr , Sn_cr_open) and then immediately going to eth_read = Wiz5500_readvalue(W5500_S0_reg, W5500_ sn_sr), not checking for previous OPEN command completion.


As @Eugeny explains, the problem seems to have occurred because you did not check the previous command.

After giving a specific command to the register, check the Socket information to see if the command was executed properly.

In this case, check the value of Sn_SR register to see if it is OPEN (0x01) :slight_smile: SOCK_INIT(0x13)


He actually does it in Case SOCK_OPEN : block proceeding to CONNECT command only when status reg is SOCK_INIT:

eth_read = Wiz5500_readvalue(W5500_S0_reg, W5500_ sn_sr)    'Is Channel Opened?'
If eth_read = Sock_init Then                                'If server mode'

Thus the issue should be somewhere else. I suspect that W5500 sets SR to 0x01 before it actually ready to accept new command, thus the right way would be first wait until CR clears to 0, and only then check SR to find out the result of command execution.


Oh, @Eugeny you’re right.
I quoted your words above, but I just talked about something else. Sorry, this is my mistake…

He must wait for Sn_CR to be cleared to zero.
In addition, it is a good idea to wait until Sn_SR exits SOCK_CLOSED :slight_smile:
(Of course, as of now, he can check this in the next Case statement.)

Below is a description of Sn_CR in the W5500 Reference Manual.

After W5500 accepts the command, the Sn_CR register is automatically cleared to 0x00.
Even though Sn_CR is cleared to 0x00, the command is still being processed.
To check whether the command is completed or not, please check the Sn_IR or Sn_SR.

Our reference in C language is as follows.

   setSn_MR(sn, protocol);
   setSn_PORT(sn, port);	
   setSn_CR(sn, Sn_CR_OPEN);

   while(getSn_SR(sn) == SOCK_CLOSED);


in addition to what @Eugeny explained in detail, it would be good for you to refer to the link below.



Hi guys, I’ve already found the problem, after hardware reset Wiz5500 takes some time for get linked up so it’s mandatory to poll bit 0 of PHICFGR register before start setting socket registers or been more specific before executes CONNECT command, that’s why I had to wait some time, just because there wasn’t a link up jet.

@Eugeny I suspected that too after I read the steps you suggest me to follow, I realize that the only thing I was not doing was the polling for Sn_CR to be cleared so I put it but it doesn’t either work, so, I did the procedure described before. According to the datasheet, Sn_SR will change just after Sn_CR have been cleared, so there’s no possibility to omit that event if I poll Sn_SR instead of Sn_CR.

Of course @kei, my code is based on that application note since it have been my main source all the time, thank you for the suggestion.

Thank you so much for your support!


Thank you for good news! I never experienced these issues for simple reason - device driving the chip is slower to initialize after power up than the chip!

You are right, I see it now. In W5100 datasheet this statement is not present. Well, even if I am not correct, I explained how it worked for me :slight_smile: and it if was not the case maybe it was worth trying anyway and prove me wrong.

@Kei can you please check within documentation and with the team and see if we can document this case?


Oops, was not the code you posted part of the whole thing?
I thought you had checked PHY LINK and proceeded.

Actually, in the module using our chip, PHY LINK is checked and then it goes to the main routine.
Or, if the time is delayed by several initialization processes, it may go without checking.

However, our Application Note does not explain this part. (It seems to be a note about the default settings afterwards)
As @Eugeny suggests, I will talk to the team in charge.

Of course you are right. However, it is more stable to check whether the command has been processed before moving the state and to skip it.

Anyway, I’m glad that your problem is solved :slight_smile:


Of course!
But, rather than documenting the issue as a separate document, we have added a note to the existing Application Note.

Please refer to W5500 Application Note : TCP :slight_smile:

Once again thank you for your enthusiastic support :slight_smile: