W5500 TCP Server Mode

TCP/IP Chip W5500
1

Hi,

I have configured the W5500 chip in TCP server mode and Receiving and Transmission is working fine.

But after some time while transmitting the Sn_IR becomes Socket Busy. The response I am getting for Sn_IR is 0x01 instead of 0x11.

Please help me!

2

There’s no such state for the socket.

Bit 4 set means SEND_OK.

Sn_IR(SENDOK) Interrupt
This is issued when SEND command is completed.

If this bit is reset, then either respective bit is not set in Sn_IMR, or there were no completed SEND command, or this bit was cleared by the user code.

3

If SEND_OK command is reset, I am making it set and transmitting again.
But sometimes I am getting Sn_SR command 0x1E or 0x2E, after that it goes to close state and again I am calling Initialization of W5500 chip.

What could be the problem?

4

SEND_OK is not a command, it is flag in Sn_IR register.

How you do it? You mean in Sn_IMR register?

Sounds like invalid states. Are you sure SPI communication is reliable?

5

I making as follows if I got wrong response
setSn_CR(sn,Sn_CR_SEND); // sn = Socket Number = 0, Sn_CR_SEND = 0x10
/* wait to process the command… */
while(getSn_CR(sn));

As of now I thought it is working properly, But is it require some delay between executing commands?

Sorry for that wrong statement.

6

What wrong response you are talking about?

SEND command is code 0x20. Code 0x10 is to close socket!

7

I am calling this function every one sec.
This library is downloaded from the github.

int32_t send(uint8_t sn, uint8_t * buf, uint16_t len)
{
uint8_t tmp=0;
uint16_t freesize=0;

CHECK_SOCKNUM();
CHECK_SOCKMODE(Sn_MR_TCP);
CHECK_SOCKDATA();
tmp = getSn_SR(sn);
if(tmp != SOCK_ESTABLISHED && tmp != SOCK_CLOSE_WAIT) return SOCKERR_SOCKSTATUS;
if( sock_is_sending & (1<<sn) )
{

**> tmp = getSn_IR(sn);**
Sometimes I am getting wrong response

_NOP() ;
_NOP() ;

  if(tmp & Sn_IR_SENDOK)
  {

     setSn_IR(sn, Sn_IR_SENDOK);
     _NOP() ;
     _NOP() ;

     sock_is_sending &= ~(1<<sn);         
  }
  else if(tmp & Sn_IR_TIMEOUT)
  {

// close(sn);
return SOCKERR_TIMEOUT;
}
else
{
setSn_IR(sn, Sn_IR_SENDOK);
_NOP() ;
_NOP() ;

	  return SOCK_BUSY;
  }

}
freesize = getSn_TxMAX(sn);
if (len > freesize) len = freesize; // check size not to exceed MAX size.
while(1)
{
freesize = getSn_TX_FSR(sn);
_NOP() ;
_NOP() ;
tmp = getSn_SR(sn);
if ((tmp != SOCK_ESTABLISHED) && (tmp != SOCK_CLOSE_WAIT))
{
// close(sn);
return SOCKERR_SOCKSTATUS;
}
if( (sock_io_mode & (1<<sn)) && (len > freesize) ) return SOCK_BUSY;
if(len <= freesize) break;
}
wiz_send_data(sn, buf, len);
_NOP() ;
_NOP() ;
setSn_CR(sn,Sn_CR_SEND);
/* wait to process the command… */
while(getSn_CR(sn));
sock_is_sending |= (1 << sn);
//M20150409 : Explicit Type Casting
//return len;
return (int32_t)len;
}

Actually this function I am calling.
setSn_IR(sn, Sn_IR_SENDOK);

8

What is wrong with this command’s response?

9

As I said I am getting 0x0E, 0x1E, 0x2E.

I am expecting 0x11 response.

Can you please guide me which software is good for TCP/IP communication testing.

10

For Sn_IR?

Or for Sn_SR?

Please do not confuse the things because if you describe your issue improperly it will be close to impossible to help you.

If 0x2E is about Sn_IR, can you figur eout what have happened using datasheet page 49?

Why? Why do you think there could be no other response than this? Do you actually reset the flags?

11

Sorry for wrong direction, The response I am getting for Sn_IR.

Yes, Because the data is transmitting properly about 40 sec, sometimes about 10 sec.

But most of the time 0x01 response I will get for Sn_IR, Actually I am again setting the SEND_OK flag, but after if I read it will be 0x01.

12

How do you “set” this flag (did I ask this question before?..)

13

This thread, May be I thought wrong,

14

I think the best at this point for you is to read datasheet regarding the information on IR/IMR and Sn_IR/Sn_IMR flags and ask exact questions on things you do not understand. So far sounds you have some idea of how it may work, but it seems it does not…

15

You wrote: “But is it require some delay between executing commands?”

Yes, it does. After sending a command you should first wait for Sn_CR to be set to zero, then check Sn_SR for the status code(s) that may result from that command (e.g., for a “CLOSE” command you’d expect Sn_SR to change to SOCK_CLOSED). See page 47 of the datasheet, which says (in part):

“Sn_CR (Socket n Command Register) [R/W] [0x0001] [0x00]
This is used to set the command for Socket n such as OPEN, CLOSE, CONNECT,
LISTEN, SEND, and RECEIVE. 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.”

In addition, I’ve found that when running with a Cortex-M4 MCU at 120 MHz I need to insert delays in loops in which I’m polling the status register. Failing to do so seems to be especially harmful when sending a CONNECT or DISCON command, both of which require a handshake with a network peer. I suspect that polling too frequently interferes with the W5500’s ability to monitor the network.

1 Like