--- title: "W5500 TCP Client CONNECT problem" url: "https://maker.wiznet.io/forum/10295" markdown_url: "https://maker.wiznet.io/forum/10295/md" type: "Forum topic" category: "Ethernet Chips" author: "Zarck" created: "2014-06-10T11:59:06+09:00" last_activity: "2018-10-21T23:58:20+09:00" language: "en" views: 11124 replies: 28 source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)" --- # W5500 TCP Client CONNECT problem ## Question Asked by Zarck on 2014-06-10 in Ethernet Chips. Hi, We are using the W5500 (W550io board) with a STM32f417. Until now, for testing purpose, we were working with a Terminal on PC (as a TCP Client) and the Wiznet module configured to be the TCP Server. No problem in this case. Now, we would like to use the Wiznet as a TCP Client. I did an initialization as it seems to be done on the datasheet but when I go to the step where I send the CONNECT Command, I always get SOCK_SYNSENT and then SOCK_CLOSED. I never get SOCK_ESTABLISHED. I will put my initialization code here, maybe you will find my problem. Note that the WriteRegister function are working well because it works with the TCP Server configuration. [code]// TCP Client void vWIZNET_InitDeviceClient(void) { uint8_t __u8_SocketStatus = 0xFF; uint8_t __au8_DataToWrite[4] = {0xC0, 0xA8, 0x01, 0x01}; vWIZNET_WriteRegisterValue(SOCKET_REGISTER_DIPR, SOCKET_0_REGISTER_BLOCK, __au8_DataToWrite, 4); // Set Destination IP address 192.168.1.1 __au8_DataToWrite[0] = 0x79; __au8_DataToWrite[1] = 0x18; vWIZNET_WriteRegisterValue(SOCKET_REGISTER_DPORT, SOCKET_0_REGISTER_BLOCK, __au8_DataToWrite, 2); // Set Destination port 31000 __au8_DataToWrite[0] = 0x01; vWIZNET_WriteRegisterValue(SOCKET_REGISTER_MR, SOCKET_0_REGISTER_BLOCK, __au8_DataToWrite, 1); // Set TCP protocol __au8_DataToWrite[0] = OPEN_COMMAND; //0x01 vWIZNET_WriteRegisterValue(SOCKET_REGISTER_CR, SOCKET_0_REGISTER_BLOCK, __au8_DataToWrite, 1); // Open command vWIZNET_ReadRegisterValue(SOCKET_REGISTER_SR, SOCKET_0_REGISTER_BLOCK, &__u8_SocketStatus, 1); // Get socket status register while(__u8_SocketStatus != 0x13); // SOCK_INIT __au8_DataToWrite[0] = CONNECT_COMMAND; // 0x04 vWIZNET_WriteRegisterValue(SOCKET_REGISTER_CR, SOCKET_0_REGISTER_BLOCK, __au8_DataToWrite, 1); // Connect command while(__u8_SocketStatus != 0x17) // SOCK_ESTABLISHED { vWIZNET_ReadRegisterValue(SOCKET_REGISTER_SR, SOCKET_0_REGISTER_BLOCK, &__u8_SocketStatus, 1); // Get socket status register } }[/code] Thank you for your help, Marc ## Replies ### Reply 1 by Zarck, 2014-06-11 More precisions: I am using ezTerm or Hercules as TCP Server, listening the Port 31000. I was thinking for a moment that it could be the Windows firewall which was blocking the port access but the OPEN_COMMAND works well. I just cannot connect to the PC and I don’t see why, I always go to Time Out. I also tried adding the subnet mask register but nothing changed. ### Reply 2 by suhwan, 2014-06-12 Dear Zarck, Would you send the packet capture ? Your code doesn’t seem to have any problem. Thanks, ### Reply 3 by Zarck, 2014-06-12 Thank you for your answer. Here are the captures. Note that it stays infinitely in the last while loop because it is never equal to 0x17. These captures are done with a terminal open as Server and listening on the Port 31000 configured in the code above. I did 3 captures to clearly see the packets. [![](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/721c4e77d91c770a0bdb5a708e957f925e5b15a5.png) 1377×255 42.6 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/721c4e77d91c770a0bdb5a708e957f925e5b15a5.png) [![](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/9e38bc1eb19debd83d6ba59c1d238633415bf25a.png) 1228×249 39 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/9e38bc1eb19debd83d6ba59c1d238633415bf25a.png) [![](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/595ff3c5b16d8909c87ef547008abbd98da8f11a.png) 1380×254 45.1 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/595ff3c5b16d8909c87ef547008abbd98da8f11a.png) ### Reply 4 by suhwan, 2014-06-13 Thank you for your the spi packet… But, we want to Ethernet packet capture. By using 'WireShark", you can capture the Ethernet packet. Please, attach Ethernet packet capture. Thanks, ### Reply 5 by Zarck, 2014-06-13 Ok Sorry. Here is a screenshot of wireshark. I think there is definitely a problem there. I just added one code line which define the Source Port at 31001 in order to clearly see it on wireshark. [![](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/57bc2d70f889adb079c24942fda9d9e6e2cabb76.png) 1816×765 91.8 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/1X/57bc2d70f889adb079c24942fda9d9e6e2cabb76.png) ### Reply 6 by suhwan, 2014-06-16 Dear Zarck, As you know, PC program do not send SYN-ACK corresponding to SYN packet from W5500. Please, check security setting or Socket program. - Check setting of firewall or vaccine program - Use another socket program. - Change port number Thansk, ### Reply 7 by Juan Esteban Lopera, 2017-05-12 Hi all, I would like to know if you have already solved this problem, I’m getting into the same trouble and I can’t go with a solution. In fact I’m following exactly the same steps as Zack did, I’ve found the way to use the chip as a server and it worked very well but when I configure it as a client it doesn’t change to ESTABLISHED state after executes the CONNECT command. Another weird situation is that when I write and then read the Sn_dport0 and Sn_dport1 registers, all I get is zero but in the datasheet these registers seems to have both W/R permissions so I don’t know what can be causing this behavior. Can you help me please? Thanks in advance, Juan Esteban ### Reply 8 by Eugeny, 2017-05-13 (in reply to reply 7) > Another weird situation is that when I write and then read the Sn_dport0 and Sn_dport1 registers, all I get is zero It is normal behavior. You will be able to read correct destination port number when connection will get established. > it doesn’t change to ESTABLISHED state Which state it is stuck in? 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. When connection is being established, there’s packet exchange in both directions, W5500 requesting connect and PC replying back with approval or denial. You should see this “network dialogue” between devices, and see if it is wrong. ### Reply 9 by Juan Esteban Lopera, 2017-05-15 Eugeny: > Which state it is stuck in? 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. [/quote] 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. [![](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/4/429361af6b8f3db3c2ab7e0b8fdfc46da6be1d74.png) 1364×1420 80.3 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/4/429361af6b8f3db3c2ab7e0b8fdfc46da6be1d74.png) 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' CODE0 ‘-------- 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 Case HANDSHAKE_ACK : 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. ### Reply 10 by Kei, 2017-05-16 (in reply to reply 9) Hello. 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. ### Reply 11 by Eugeny, 2017-05-16 (in reply to reply 9) ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > ``` Call Wiz5500_writevalue(W5500_Common_reg, W5500_sn_dipr0 , 192) Call Wiz5500_writevalue(W5500_Common_reg, W5500_sn_dipr1 , 168) Call Wiz5500_writevalue(W5500_Common_reg, W5500_sn_dipr2 , 1) Call Wiz5500_writevalue(W5500_Common_reg, W5500_sn_dipr3 , 51) ``` DIPR (destination IP address register) is located in S0_reg block, not in common register block. ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > ``` Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_dport0 , &H1B) 'Sets source port number =7000' Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_dport1 , &H58) ``` Comment seems to be wrong, you set destination port. ### Reply 12 by Juan Esteban Lopera, 2017-05-16 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. ### Reply 13 by Juan Esteban Lopera, 2017-05-16 Eugeny: > DIPR (destination IP address register) is located in S0_reg block, not in common register block. 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. ### Reply 14 by Eugeny, 2017-05-16 Perform the following already existing code ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > … > > ``` 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) ``` 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. ### Reply 15 by Juan Esteban Lopera, 2017-05-16 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. ### Reply 16 by Eugeny, 2017-05-16 ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > I can’t read the values written on Dst port and IP regs 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. ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > I have put those instruction within a infinite loop 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). ### Reply 17 by Juan Esteban Lopera, 2017-05-16 Eugeny: > please set DIPR and DPORT values before you issue OPEN command I’ve just did it but nothing changed ![:confused:](https://emoji.discourse-cdn.com/twitter/confused.png?v=12). Eugeny: > you should NOT write anything to W5500 in infinite loop. Sorry I know I should not do such a thing but I’m a little bit desperate. ### Reply 18 by Eugeny, 2017-05-16 ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > I’ve just did it but nothing changed ![:confused:](https://emoji.discourse-cdn.com/twitter/confused.png?v=12) 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. ### Reply 19 by Juan Esteban Lopera, 2017-05-16 Hi, 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. [![](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/0/01855f2a66432daac74d9c6ed16ecba1d3f60584.PNG) 1131×646 30.6 KB](https://maker.wiznet.io/forum_uploads/wiznet/original/2X/0/01855f2a66432daac74d9c6ed16ecba1d3f60584.PNG) Thank you so much for your help. Best regards. ### Reply 20 by Eugeny, 2017-05-17 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. ### Reply 21 by Kei, 2017-05-17 ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > It seems that it’s necessary to wait a minimum time of 800ms (for client mode) between the execution of OPEN and CONNECT commands Eugeny: > Your code was missing “you issue OPEN command into S0_CR, and wait until this register clears to 0” As [@Eugeny](https://maker.wiznet.io/u/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:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) SOCK_INIT(0x13) ### Reply 22 by Eugeny, 2017-05-17 Kei: > 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:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) 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. ### Reply 23 by Kei, 2017-05-17 Eugeny: > 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](https://maker.wiznet.io/u/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:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) (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](https://github.com/Wiznet/ioLibrary_Driver/blob/master/Ethernet/socket.c) is as follows. ``` setSn_MR(sn, protocol); setSn_PORT(sn, port); setSn_CR(sn, Sn_CR_OPEN); while(getSn_CR(sn)); while(getSn_SR(sn) == SOCK_CLOSED); ``` ### Reply 24 by Kei, 2017-05-17 in addition to what [@Eugeny](https://maker.wiznet.io/u/eugeny) explained in detail, it would be good for you to refer to the link below. [W5500Application:TCP](http://wizwiki.net/wiki/doku.php?id=products:w5500:application:tcp_function) ### Reply 25 by Juan Esteban Lopera, 2017-05-17 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 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. [@Eugeny](https://maker.wiznet.io/u/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. Kei: > it would be good for you to refer to the link below. > W5500Application:TCP Of course [@kei](https://maker.wiznet.io/u/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! ### Reply 26 by Eugeny, 2017-05-17 (in reply to reply 25) ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > 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 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! ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > According to the datasheet, Sn_SR will change just after Sn_CR have been cleared 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:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) and it if was not the case maybe it was worth trying anyway and prove me wrong. [@Kei](https://maker.wiznet.io/u/kei) can you please check within documentation and with the team and see if we can document this case? ### Reply 27 by Kei, 2017-05-18 (in reply to reply 25) ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > 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. 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](https://maker.wiznet.io/u/eugeny) suggests, I will talk to the team in charge. ![](https://avatars.discourse-cdn.com/v4/letter/j/e47774/48.png) Juan_Esteban_Lopera: > 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 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:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) ### Reply 28 by Kei, 2017-05-18 Eugeny: > [@Kei](https://maker.wiznet.io/u/kei) can you please check within documentation and with the team and see if we can document this case? 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](http://wizwiki.net/wiki/doku.php?id=products:w5500:application:tcp_function) ![:slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) Once again thank you for your enthusiastic support ![:slight_smile:](https://emoji.discourse-cdn.com/twitter/slight_smile.png?v=12) --- Source: https://maker.wiznet.io/forum/10295