UDP packets not sent successfully immediately after initialization

Question

Hello, 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: W5100 experiences mismatched TX pointer error as described in errata list. Microcontroller interfacing with W5100 closes socket, disables all interrupts from W5100, then asserts a hard reset. 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. After another 20 ms, microcontroller reloads unsucessfully sent UDP msg into W5100, then asserts SEND cmd. 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) 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!

becky · Answer

Hello, 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.

Eugeny · Answer

brian_ruiz: asserting a software reset to the W5100 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?

brian ruiz · Answer

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. Brian

Eugeny · Answer

brian_ruiz: Is the software reset a valid solution in this case 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.

brian ruiz · Answer

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.

brian ruiz · Answer

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?

brian ruiz · Answer

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?

Eugeny · Answer

Errata says 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!