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!
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.
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?
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?
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?
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!
