UDP packets not sent successfully immediately after initialization


In response to the “mismatched TX pointer errata” listed in the official W5100 list (link here: https://www.google.com/url?sa=t&source=web&rct=j&url=http://techw.c.ooco.jp/Download/3150A_5100_errata1_Eng.pdf&ved=2ahUKEwixqe-V4IrdAhVGU98KHT9CC9gQFjAGegQIARAB&usg=AOvVaw2io0RxrtUPm1sVOLlUCp1l&cshid=1535287701836) I have made a program which is able to recall and reload an unsucessfully sent UDP message into the W5100 ~40 ms after hard reset/re-initialization. What I have noticed though is that after asserting the SEND command once the message is reloaded into the W5100’s TX buffer, the W5100 asserts a TIMEOUT interrupt rather than a SEND_OK for ~2 seconds before finally being able to send the message out successfully. Is this expected behavior, or is there something wrong with my re-initialization process?

Series of events:

  1. W5100 experiences mismatched TX pointer error as described in errata list.
  2. Microcontroller interfacing with W5100 closes socket, disables all interrupts from W5100, then asserts a hard reset.
  3. After 20 ms, microcontroller re-inits W5100, waits for S/W reset bit in MR to become ‘0’ then inits IP addr, gateway addr, MAC addr, subnet mask, TX/RX memory, retry time/count, socket parameters, etc… (I assume my initialization process is correct since initialization prior to hard reset due to errata case works fine) then re-init interrupts on microcontroller.
  4. After another 20 ms, microcontroller reloads unsucessfully sent UDP msg into W5100, then asserts SEND cmd.
  5. W5100 tries to send msg, but asserts “TIMEOUT” interrupt instead. (steps 4-5 repeat for about 2 seconds, microcontroller will keep reloading msg if timeout interrupt received)
  6. W5100 finally asserts “SEND_OK” interrupt and msg can be seen on Wireshark.

Does anyone have insight on how this 2 second delay time in which the W5100 is not able to send a msg out successfully can be reduced? If more information is needed please let me know. Thank you!

The timeout interrupt in udp occurs when a reply to an arp request is not received.
Apart from the errata of the w5100, I think it is because you sent the udp data before the link was assert after the chip was reset.
Make sure you send the data after the link is asserted.

1 Like

Hi Becky,

Thank you for your insight. Ultimately, I have found that asserting a software reset to the W5100 when the errata case is reached is sufficient. I am interested in learning about how one would be able to find when the WIZNET asserts a link to its peer, do you have pseudocode that implements this in UDP mode? Thanks again!


This will not be a good solution is the chip is having other sockets running, for example TCP. Is it possible to solve the issue at the socket level only as advised by the errata sheet?

Hi Eugeny,

Fortunately, we only have socket zero open and we’re running in UDP mode. Is the software reset a valid solution in this case? When asserting a hardware reset, we noticed a two second delay in sending a response from the W5100 to its peer, which is not satisfactory in our application.


In your particular case yes, but may not in other cases. Why you just do not close and reopen the socket 0? It should be even faster than software reset.

We close and re-open the socket upon any socket zero related interrupt. For example, if we get a successful send interrupt, we acknowledge the interrupt, close the socket, then re-open it prior to completely exiting the interrupt service routine. In the case in which we implemented the hardware reset, we saw that the microcontroller (uC) would get a timeout interrupt upon sending the missed response after reset and the interrupt service routine would close, then open the socket every time the uC would get a timeout. Unfortunately the closure and reopening of the socket did not reduce or prevent the two second delay we were seeing.

You do not need to close socket to reuse it for the same purpose. I even think that it is possible to change UDP socket setup on the fly, without reopening it. So you seem have chosen strange way to drive the chip…

Do you think that the closing and re-opening of the socket upon any socket zero related interrupt may be placing the W5100 into the errata state described above?

As I understand it is other way around - when errata state is detected, you must close and open socket. It is actually written in the errata document.

The way that I understood the errata is to reset the W5100 in the case that we reach the mismatched TX pointer state. Would simply closing and reopening the socket in the case of the listed errata “reset” the W5100?

Errata says

  1. If the two values are still different, close the socket by force RESET.
    Refer to following pseudo-code.

IMHO it means write CLOSE command to the command register. But as you write I also start to doubt about it - as there’s no “RESET” to close the socket!