Strange operation of the chip in TCP mode

TCP/IP Chip W5500
1

I have the illogical behavior of the chip in the “Tcp-client” mode.
If you physically remove the cable from the connector while sending a TCP packet and waiting for a response from the server (ACK), after a few fractions of a second, the “SendOk” bit is set in the socket interrupt register, although it is obvious that it is impossible to receive ACK until there is a physical connections.
I could not find an explanation for this phenomenon in the documentation.

Have you come across this?

2

It must be proven that ACK message was NOT delivered before you disconnect cable.

Please provide the way to reproduce the issue reliably. As far as I see, it will be about blocking the ACK packet from remote device, and seeing what W5500 is doing.

3

The sequence is simple:

  1. Open the socket in TCP mode.
  2. Connect to a remote server.
  3. Send a data packet.
  4. Waiting for setting the SendOK flag from the socket interrupt register.
  5. Clear the Send Ok flag
  6. Return to 3.

If during the execution of this algorithm, after the connection is established, to disconnect the cable, the Send Ok flag will be set to 1 after a short time. And only after 2-3 packets it will be set together with the timeout bit from the interrupt register.

UPD.
One more way:
You need PC with 2 network adapters;

  1. Set the net bridge between adapters;
  2. Connect your HW to remote server;
  3. Send Packet
  4. Wait until SendOk be sets 1;
  5. Clear SendOk flag
  6. Repeat from 3)

While this script running, you can remove net bridge and see result.

4

Would be good to check TX_FSR register to see if it shrinks. It may be possible that while SENDOK is set, W5500 still keeps data in the buffer and perform retries. And timeout is got set when buffer gets full. Let’s wait for response of someone from WIZnet.

5

Thank you for answer.
I not immediately understood, what you means, but as soon as I began to check the completion of delivery upon clearing the TX buffer, the problem was solved.