The W5100 unexpected DISCON interrupt

I have a problem with W5100.

I’m using W5100 as a TCP-server. And sometimes W5100 stops sendind TCP-packets and asserts DISCON interrupt. Usually, there are one or more broadcast ARP-packets.

The W5100 (IP 192.168.8.249, port 8888) and a PC (IP 192.168.8.88) are connected to one switch in a LAN. The uC reads TCP-data from the W5100 and re-sents the same data back (using DMA).

Log from the PC.
W5100_RST_flag1.zip (791.6 KB)

The supposed sequence of events (from Wireshark and uC logs):

  1. The last data sent from PC to W5100 is Packet #27475
  2. Next packet was a broadcast ARP-packet.
  3. uC read data from packet #27475 and sent data back to W5100 (starts DMA writing). On PC (Wireshark log) there was no answer from W5100 (no TCP-data, no empty TCP-packet with ACK flag).
  4. 300ms later
    Packet #27477 - first TCP retransmission from the PC
    TIMEOUT interrupt from the W5100 socket (Socket Status Register was 0x08),
    no actions in uC.
  5. 300ms later
    DISCON interrupt from the W5100 socket, uC inited the W5100 socket.
  6. 300ms later
    Packet #27481 - second TCP retransmission from the PC
    Packet #27482 - W5100 sent RST flag (because socket is closed)

I didn’t close connection neither in W5100 server, nor in PC client.
Why W5100 asserts TIMEOUT and DISCON interrupts?

This issue may not be directly caused by the W5100, the switch may bug the operation. As W5100 is not much sophisticated in restoring from the network error state, it will just fail the connection at its end (and this is what you see).

I recommend you doing the following: place PC (Windows or Linux) in bridge mode between W5100 and the switch with Wireshark running, and compare logs on the client (.88) and this bridge PC.

I’ve done tests with the ethernet-bridge. The client log is the same.
But in a bridge log (of adapter to the LAN/switch) I could see, that W5100 sent answer and both client and W5100 sent TCP retransmissions.
The total time of W5100 retransmissions was about 210ms (RTR=30ms, RCR=3), and after the last W5100 retransmission TIMEOUT interrupt asserted.

It looks like the switch stops transmitting TCP-packets from W5100 to client PC for a while, but transmits all TCP-packets from client PC to W5100.
But some time later (less than 900ms), the switch starts transmitting TCP-packets from W5100 (the RST-packet).

And I’ve decided to increase the W5100 total retransmissions time by RCR=6.