W5300 MACRAW Rx FIFO overflow condition

Question

Hello, I have been using W5300 in MACRAW mode for receiving Ethernet packets and it was working fine. But now I have found that during sudden inrush of data in the network the FIFO overflows. FIFO overflow is acceptable but now I have to recover from it. I’m referring to w5300 datasheet(version 1.2.8), quoting it below for ease of reference “In case that the free size of internal RX memory is smaller than 1528 - Default MTU(1514)+PACKET-INFO(2)+DATA packet(8)+CRC(4) - close SOCKET 0. After closing the SOCKET0, Process all received MACRAW data and then reopen the SOCKET0.” In the code snippet, packets are received, and while receiving packet after packet, the received size is reduced "recved_size = recved_size – 2 – pack_size – 4; " From my understanding the RX FIFO size includes the dummy byte (if odd bytes are received) and hence it is never odd. But the length specified in packet info does not include this dummy byte. So shouldn’t an additional byte be deducted from the rx fifo count if packet count is odd? recved_size = recved_size – 2 – pack_size – 4 - 1(if received odd packet); Are all the packets received after closing the FIFO valid ones? Also, could I just close and reopen the socket and skip the packet reception part if I’m not interested in processing the received packets after overflow? Thank you!

lr15 · Answer

So per my first question and your response to that, the data sheet "recved_size = recved_size – 2 – pack_size – 4; " is wrong. Instead recved_size = recved_size – 2 – pack_size – 4 - 1(if received odd packet); should be done. Correct? In your testing, what’s 4096? I guess I’ll rephrase my question! All my questions are on the condition when an overflow happens. So, “On overflow condition, after closing the FIFO, are all the packet read from the FIFO valid?” Can you test it by letting the FIFO overflow(REMAINING SPACE IN FIFO < (ALLOCATED FIFO SIZE - 1528)) and also add packets with odd bytes? When you say W5300 doesn’t support flushing, you mean closing and reopening the socket will not clear(reset) and thus empty it’s FIFO’s? Which means the old data will be present even after closing and reopening the socket and I have to read the Sn_RX_FIFOR before starting the next reception? I appreciate your response. Thanks!

lr15 · Answer

The following is from page 115 in w5300 datasheet(version 1.2.8) /* calculate the size of remained data in internal RX memory*/ recved_size = recved_size – 2 – pack_size – 4; Let’s say two odd packets were received back to back. 101 + 101. Now the Sn_RX_RSR would be {2(packet info) + 101(data) + 1(dummy data) + 4 (crc) = 108} * 2 = 216 From the math, recved_size = recved_size – 2 – pack_size – 4; After processing the first packet, I’ll end up with recevied_size = 216 - 2 - 101 - 4 = 109. The received count should be 108. I would subtract (read_cnt * 2) instead of pack_size in that equation. It doesn’t make sense to me, perhaps I’m missing something here. If nothing gets corrupted, I don’t understand why the user should close and reopen the socket? Quote from page 114 "Notice: In case that free buffer size of internal RX memory is smaller than the size of receiving MAC RAW data, some parts of un-acceptable PACKET-INFO and DATA packet of the MACRAW data can be saved in internal RX memory. This can cause the error in analyzing PACKET-INFO (as shown in above code), and receiving correct MACRAW data. This problem is more likely to happen when internal RX memory gets close full. This can be solved by ignoring some loss of MACRAW data. " Could you explain the above statement? Since closing and reopening would empty the socket buffer and make Sn_RX_RSR = 0. I’ll give that a try and see if it works.

lr15 · Answer

[quote=“lr15”]1. The following is from page 115 in w5300 datasheet(version 1.2.8) /* calculate the size of remained data in internal RX memory*/ recved_size = recved_size – 2 – pack_size – 4; Let’s say an odd packet was received - 101 bytes. Now the Sn_RX_RSR would be 2(packet info) + 101(data) + 1(dummy data) + 4 (crc) = 108} From the math, recved_size = recved_size – 2 – pack_size – 4; After processing the first packet, I’ll end up with recevied_size = 216 - 2 - 101 - 4 = 109. The received count should be 108. I would subtract (read_cnt * 2) instead of pack_size in that equation. It doesn’t make sense to me, perhaps I’m missing something here. If nothing gets corrupted, I don’t understand why the user should close and reopen the socket? Quote from page 114 "Notice: In case that free buffer size of internal RX memory is smaller than the size of receiving MAC RAW data, some parts of un-acceptable PACKET-INFO and DATA packet of the MACRAW data can be saved in internal RX memory. This can cause the error in analyzing PACKET-INFO (as shown in above code), and receiving correct MACRAW data. This problem is more likely to happen when internal RX memory gets close full. This can be solved by ignoring some loss of MACRAW data. " Could you explain the above statement? Since closing and reopening would empty the socket buffer and make Sn_RX_RSR = 0. I’ll give that a try and see if it works.[/quote]

lr15 · Answer

Okay, I did some testing last couple days to handle the rx FIFO overflow condition in MACRAW mode. When overflow happens, just closing and reopening the socket leads to bad packet info(the length of the received packet is more than 1514). I was expecting everything to be reset and just work fine but it is not. I guess this should be easily reproducible in your set up too. Since closing and reopening failed, I decided to read the RX FIFO out as per the code in w5300 datasheet. This also gives bad packet info. Analyzing more into this, I see that the S0_RX_FIFOR shows one value before closing the socket and shows another after closing the socket. So I believe the S0_RX_FIFOR after closing the socket must be used to process the data. Seems like some irrelevant data(perhaps from previous packet) is put in the rx fifo when overflow occurs. Even after closing the socket? Should I wait for sometime before reopening the socket/ after reopening the socket? I’ll do more testing and post results in a few days. I’ll appreciate if you can confirm whether my testing results makes sense to you and you can reproduce it. Thanks!

lr15 · Answer

Okay, from what you have said I understand that packet_info bad means overflow has happened already before I could check for the condition(<1528). Now the FIFO data is definitely bad and I need to close and reopen the socket. So, I’m going to close and reopen the socket on two instances. Overflow is about to happen - When the remaining size of the FIFO < 1528 Overflow has happened - When the packet_info is bad. There is definitely going to be a loss of data on FIFO overflow on the second condition. This is mainly because I’m not able to read the data out faster from the RX FIFO. But, loosing the already received data is bad. I think this should be in the errata even if its mentioned in the datasheet. I appreciate your quick response midnightcow!

lr15 · Answer

When overflow happens, the FIFO gets corrupted and it is identified when the packet_info is bad. Detecting corruption of the FIFO is based on packet_info. The problem is, there is no guarantee that when the overflow happens the packet_info would be always greater than 1514 bytes. It is just random bytes from the stream. So it could also be lesser than 1514 but wrong(bad). So the user could be reading the corrupted FIFO since the packet info is less than 1514. This will eventually lead to bad packet_info and the user will detect overflow. But the previous packets read could be bad. So when working in MACRAW mode, CRC must always be used to ensure the packet is good.