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.
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.
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.
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.
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.
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
(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.
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 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 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?