W5500 TCP Client CONNECT problem

Question

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

Zarck · Answer

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.

suhwan · Answer

Dear Zarck, Would you send the packet capture ? Your code doesn’t seem to have any problem. Thanks,

Zarck · Answer

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. 1377×255 42.6 KB 1228×249 39 KB 1380×254 45.1 KB

suhwan · Answer

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,

Zarck · Answer

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. 1816×765 91.8 KB

suhwan · Answer

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,

Juan Esteban Lopera · Answer

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

Juan Esteban Lopera · Answer

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. 1364×1420 80.3 KB 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 =5000' Call Wiz5500_writevalue(W5500_S0_reg, W5500_sn_port1 , &H88) 'Sets source port number low byte =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…

Juan Esteban Lopera · Answer

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.

Juan Esteban Lopera · Answer

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.

Eugeny · Answer

Perform the following already existing code 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.

Juan Esteban Lopera · Answer

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.

Eugeny · Answer

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. 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).

Juan Esteban Lopera · Answer

Eugeny: please set DIPR and DPORT values before you issue OPEN command I’ve just did it but nothing changed . 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.

Eugeny · Answer

Juan_Esteban_Lopera: I’ve just did it but nothing changed Hm… this is strange. Let’s review everything again, thread is relatively long and code is kind of messy in it, so: 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; 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); I never worked with no gateway configurations, I think you can leave GAR uninitialized; 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); You preset DIPR, SPORT and DPORT (socket 0 registers); 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); 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.

Juan Esteban Lopera · Answer

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. 1131×646 30.6 KB Thank you so much for your help. Best regards.

Eugeny · Answer

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.

Kei · Answer

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 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) SOCK_INIT(0x13)

Eugeny · Answer

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) 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.

Kei · Answer

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 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 (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_CR(sn)); while(getSn_SR(sn) == SOCK_CLOSED);

Kei · Answer

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

Juan Esteban Lopera · Answer

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 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, 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!

Kei · Answer

Eugeny: @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 Once again thank you for your enthusiastic support