TX Buffer Jam

TCP/IP Chip W5300
1

or TX FSR zero jump with TX Buffer not full

Dear WIZnet Team,

Situation
we use the W5300 chip to send measurement data from hardware to a PC. The W5300 is connected directly (no switch) via 100Mbit LAN to the PC. Data packets are 1460 Bytes and data rate is 1.16 Mbps. The data is sent continuously. The socket (S0) is configured as a TCP socket and is only used for sending. The TX buffer size is 64KB (RX buffer is 8KB). The WIZnet chip is configured via an FPGA using 16-bit direct addressing. Sending routine is implemented as described in the data sheet: check SSR, check SENDOK, check FSR, write 1460 bytes to S0_TX_FIFOR, write S0_TX_WRSR, write S0_CR, check SSR, etc.
Three sockets are used: the described S0 TCP socket, another TCP, and an UDP socket. But most of the time only S0 is used.

Problem
Most of the time the sending process works well but sometimes data packets get lost.
To investigate the problem, we integrated an analyzer on the FPGA side and observed the data stream on the PC side with Wireshark.
The analyzer showed that the send routine sometimes hangs because the TX FSR is zero (the buffer for the measurement data then overflows and data is lost). The strange thing is that the TX FSR shows 0 long before the TX buffer is full.
On closer inspection, the FSR always was on 43636 bytes before the next value was 0. I.e. if there were 15 packets in the TX buffer (65536 - 43636 = 21900 / 1460 = 15), the FSR showed 0 next. After a certain time, the FSR jumped back to the old value 43636 and transmission routine was continued. To observe the behaviour in wireshark, the FSR value was written in each packet and also a marker in the first packet sent after the “FSR-zero-pause”.

wireshark-brdyMarker-fsr-e
wireshark-brdyMarker-fsr-e1770×1076 159 KB

During the FSR-zero-pause the SSR is 0x0917. According to [this breakdown] (W5300 SENDOK and Reserved Status Byte), a reserved byte = 9 (1001) means

  • 3rd Bit: No more transit until ack number is received.
  • 0th Bit: Tx buffer full
    But as can be seen in wireshark, the matching ACKs are sent without delay and the TX buffer cannot yet be full.

A similar problem was described by jmattfeld in Feb. 19

Approaches we tried in vain to solve the problem

  • Check TMSR, RMSR and MTYPER, try different sizes
  • Do the Memory Test: “How to Test Internal TX/RX Memory in W5300” => O.K.
  • Use BRDY instead of reading FSR to check TX-Buffer free size => confirms FSR-Zero-jump
  • Use an other socket
  • Check read and write timings
  • Check all W5300 register values
  • Lower the data rate
  • Sending bigger or smaller packets
  • Put check SENDOK after write S0_TX_FIFOR (before write S0_TX_WRSR)
  • Write to S0_TX_FIFOR without checking FSR

Question
Is there anyone in the wiznet team who was maybe involved in the development of W5300 chip and has an idea about the cause of this behaviour?

Thank you very much

2

Sounds weird, but I suspect such weird things can be caused by the subtle small issues in the code and in the timing. While I am not familiar with W5300, let me give several suggestions, related to the process.

check SENDOK: Sn_IR requires interrupt bits to be reset. Do you reset this bit after you noticed it set?
write S0_CR: before going checking SSR, read Sn_CR in loop until it reads as 0 (command accepted).

3

Hello Eugeny,

thank you for your answer.

Yes, I do.

I have not yet checked the command register and have implemented your suggestion.
But the strange behaviour unfortunately persists.
The analyzer shows that the command register is set to 0 immediately after writing.

4

Look at the page 98 of the datasheet for notice. While it does not relate to your case, I see that in your packet log the w5300 window size is 8190, this means there’re 2 bytes waiting to be received in the RX buffer. Try adding small process into your workflow reading data from the RX buffer as it arrives and see if it will change anything.

5

Hello Eugeny,
sorry for my late feedback. I’m very absorbed by an other problem at the moment. I will try the reading routine and report back here with the result. Thank you very much for your careful observation and your suggestion!

However, I don’t quite understand how a missing read can contribute to the fact that the TX buffer cannot contain more than 16 data packets. RX and TX buffers are separate, aren’t they?
Is there a connection that I don’t understand?

6

You are right, I also have no clue what is going on, suspecting that W5300 is long live product and there would be such an issue it would be reported to date (e.g. in errata sheet), otherwise we have some issue in configuration or algorithms and I am searching for anomalies to get a clue on what is going on.