How to detect receive of ACK packet?

Question

Is any way to detect moment when W5500 got acknowledge (ACK) after sent data? Because Sn_IR_SENDOK only mean - data is gone, but not show about data is received by second side. Watch to absent Sn_IR_TIMEOUT during RCR&RTC timeout it’s ugly and slow method. How to be sure about that the data is delivered fully?

acpie360 · Answer

Are you talking about a TCP packet? The fact that a TCP packet can be successfully sent means the packet has been successfully delivered. I am using Wiznet’s ioLibrary, the TCP send() API says: /** * @ingroup WIZnet_socket_APIs * @brief Send data to the connected peer in TCP socket. * @details It is used to send outgoing data to the connected socket. * @note It is valid only in TCP server or client mode. It can't send data greater than socket buffer size. * In block io mode, It doesn't return until data send is completed - socket buffer size is greater than data. * In non-block io mode, It return @ref SOCK_BUSY immediately when socket buffer is not enough. * @param sn Socket number. It should be 0 ~ @ref \_WIZCHIP_SOCK_NUM_. * @param buf Pointer buffer containing data to be sent. * @param len The byte length of data in buf. * @return @b Success : The sent data size * @b Fail : @ref SOCKERR_SOCKSTATUS - Invalid socket status for socket operation * @ref SOCKERR_TIMEOUT - Timeout occurred * @ref SOCKERR_SOCKMODE - Invalid operation in the socket * @ref SOCKERR_SOCKNUM - Invalid socket number * @ref SOCKERR_DATALEN - zero data length * @ref SOCK_BUSY - Socket is busy. */ int32_t send(uint8_t sn, uint8_t * buf, uint16_t len);

acpie360 · Answer

You are correct - The immediate return from send() does not indicate the SEND command is completed. However, the subsequent send() will. This is because the real SEND status is checked at the beginning of the send() function. 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); if (tmp & Sn_IR_SENDOK) { setSn_IR(sn, Sn_IR_SENDOK); sock_is_sending &= ~(1 << sn); } else if (tmp & Sn_IR_TIMEOUT) { close(sn); return SOCKERR_TIMEOUT; } else { return SOCK_BUSY; } } … }

Eugeny · Answer

bart112233: Is any way to detect moment when W5500 got acknowledge (ACK) after sent data? You raised very interesting and useful question, and I think the only person able to have definite answer is the developer of the chip. bart112233: Seems Sn_IR_SENDOK flag sets when data sent, not then ACK packet received. I guess that Sn_CR is also cleared on this event - when packet is went into the wire. So if packet is lost, like in your case, W5500 will not immediately know if it was not delivered. bart112233: after every sending and then will disconnect on timeout. This is actually a good thing - meaning that W5500 still monitors the ACK packets; not seeing them coming it assumes that media is broken and raises timeout (and closes the socket). Another test would be more interesing though: you send a number of packets, and before timeout occurs, restore the connection so that another network device get the rest of the packets. That device, for sure, will stall saying to W5500 that it did not get [revious packets (as TCP keeps track of data/packet sequence). What will happen then? Will W5500 still have missing data to resend? In my opinion, while SENDOK is being set, W5500 should NOT free data buffer until it gets acknowledge for data received by the remote network node. For example, initially TX has 2048 bytes free, you put 512 bytes in and perform SEND. W5500 says that SENDOK, but TX buffer is having 1536 bytes free until chip gets ACK for the packet send related to this data. But it is my guess how it should be implemented, and I hope it is done so.

bart112233 · Answer

Eugeny, you was right. I was made some tests and had seen - it’s posible to use value of Sn_TX_FSR as indirect ACK-received flag. This is not ideal solutions (couse no interrupts and you must check this register periodicaly), but is much better than nothing. Many thanks to you again.