Wiznet W5300 data stuck in TX buffer

Hello! I’m using Wiznet W5300 with Spartan-6 in 16bit mode for sending data to PC through TCP/IP. Spartan is clocked by 25 MHz, Wiznet TX buffer size is 32 KB. I implement sending process in accordance with algorithm in W5300 DS. But I faced strange thing. When I decrease time of write operation to Wiznet registers to less than 7 clock tacts (~280 ns), some of sended data are stuck in TX buffer. For example I send 1 MB, but PC gets only 980 KB. After increasing write time to 8-9 clock tacts data are sended correctly. Did anyone faced with problem like this?

Wireshark output of the session would help to see what is going on the network - in both cases.

Thanks for quick response! Here the WS output sessions. I checked both cases again, fixed some errors and find out, that data get stuck in TX buffer when WR time is less than 4 FPGA tacts (160 ns).

I send 32 bit counter data to PC. Device IP is, port is 5000, packet size is 512 bytes. If WR time is less than 4 tact, almost all data are sended correctly except last 12-13 KBytes. When WR time increases to 4 tact, all data are sended correctly.

PS: Files with “.pcapng” aren’t allowed to upload, so I add “.pdf” after their name.

wr_time_120_ns.pcapng.pdf (1,5 МБ)
wr_time_160_ns.pcapng.pdf (1,5 МБ)

I do not see anything wrong in the wireshark logs, looks like W5300 just does not send the data. Your application thinks that data is sent, judging by looking at the activity on port 5001.

  1. Draw (or better observe with scope) your access cycle. It is important to see how control signals relate to each other, and to the next access cycle, and there’s no timing violation;
  2. Compare files you get - do they have same contents till the interruption?
  3. Datasheet does not state explicitly, but I suspect that just after you issue command to W5300, in your case SEND, you must check that W5300 has properly accepted the command and Sn_CR is cleared to 0, and olny then proceed to further checks and actions.

Sorry for slow response, I managed to go back to that job only now.

  1. Here’s the screenshot of my read and write cycles in scope.
  2. Yes, files have same content before interruption.
  3. I tried, it didn’t help.