W5500 of our machine didn’t work august,last year, the RST of firmware had no effect, only after power off and power on, the machine can work normaly.
Today, it happend again.
The MCU and switcher always worked normaly,only W5500 can’t work. The FAE told ne ,maybe the PHY of W5500 crashed.
I have used the Network transform.
How to find the reason of these problems? How to solve it?Thanks
The cause can be anything from wrong crystal used in the device to the application (driver) performing wrong actions on the chip.
How it does not work? Is link LED turned on? Is chip accessible through SPI? What device at another physical end (switch) sees?
Is there any evidence of the PHY overheating? Which conditions your board operates in?
What is it? Gaming API?
First of all you need to find the way to reproduce the problem.
And then, when you will find a way to reproduce it, start debugging it finding in which state chip is, can it be software-reset, would it be just enough to reset PHY, or there’s some software bug, or chip just overheats, or you have component layout on the board, EMI, crosstalk or whatever.
I need more detail information.
How didn’t work?
Just not operating RST? or not operating chip?
And Is it use 25Mhz in crystal?
If crystal is 25Mhz, you check load capacitor.
And it need more debugging information.
Thanks your help ，and I find some problem by using Wireshark. My machine‘s IP is 192.168.111.215, but the IP become 145.72.90.141 after later. At the same time,the server‘s IP become wrong,the IP came from a old message.
The appearance i found only are that, the new IP is part of the machine‘s MAC adress, and the server IP came from a old message.
I found some new, please analyse for me ,thanks
Your problem seems to be that you try opening another concurrent TCP connection to the same remote host with the same source and destination port numbers. It is not allowed; you must use at least one different value for these three. The obvious different value would be source port.
Thus if you open one connection, you use
Remote IP=192.168.1.100, source port=60005, remote port=60005
And when you open second connection, you may use
Remote IP=192.168.1.100, source port=60006, remote port=60005
In general reusing TCP ports is not a good practice, because if old port combination is still cached on the server side, its TCP/IP stack goes crazy and denies both connections.
Because something ,maybe the network is in high pressure, our machine can’t get the response from Server，so it try to link again and uses the old port.
According to what you said，I should use a new port to connect the Server?Just like: Remote IP=192.168.1.100, source port=60006, remote port=60005.
If connection is really lost, you have to connect again from the scratch - you do not have any other way with the W5500 TCP/IP stack (you can not see what exactly going on in the network - e.g. RST packet, retransmissions etc). The only indication you can get from W5500 is socket reset state and timeout interrupt bit setting. If it happens, you start everything from scratch. And unless you set up remote server to check and reply only for the remote machine having local port 60005, you must use another local port to ensure you are able to connect to its TCP/IP stack properly within short timeframe.
Thus yes, please use another source port (60006) when connection drops (you see that socket is closed and/or respective bits are set in Sn_IR).
