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.
1 Like
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)
1 Like
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.
1 Like
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);
1 Like
in addition to what @Eugeny explained in detail, it would be good for you to refer to the link below.
1 Like
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!
3 Likes
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?
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
1 Like
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
2 Likes
