I’m using the W5200 chip successfully in more than 50 boards, but have a non critical issue I would like to solve.
After powering the chip, initializing (using UDP) and opening a socket, reception is possible inmediately; however transmission is not possible for a while. The chip responds to a ping, but when trying to transmit, it returns 0 instead of the number of bytes that I’m trying to send. After 10, 20 or more retries during several seconds, the chip finally starts transmitting. After that, it works fine until the next time it is powerd on. What could be the reason for this behavior?
Not garanteed the reset time of chip.( over 150ms)
Ethernet link is unstable. (Internal ethernet phy takes time for auto-negotiation processing.)
===>To chekc link status, check the pin 5(nLINKLED) to go low or check the the 5th bit of PHYSTATUSR to set as ‘1’
After powering up the board, the nRST pin is held low for 1ms to cause a reset.
After that there is a wait of 150ms before start configuring the chip.
After configuring the chip, the same procedure is done to reset the chip again.
The LINK byte of the PHY STATUS register has the value of 1 permanently
The chip can receive without problem, reponds to a ping, but it does not transmit anything for a while.
Hi
I was making some tests and found the following:
I did not mention, as I thought it was not relevant, that the application is also configuring at power on the Retry_time and Retry_count registers. I’m setting Retry_time=50 (5ms) and Retry_count = 1 (I do this because with the default values, if there is no HOST, the W5200 halts the application for quite some time)
When removing this part of the initial configuration, the problem dissapears
So what I’m doing now is sending anything before configuring Retry_time and Retry_count. In this case there is no problem. I don’t understand why, though.
The problem with the previous solution is that it only works if the Retry registers are configured after a succesfull transmission. This means that if there is no Peer available during power on, I cannot configure these registers.
This is a problem in my aplication because it sends a message looking for a Peer every second. This means that every second the application will be halted by the W5200 while it retries until it finds a Peer, which is a lot of time with the default values.
Looking for the LINK bit of the PHY STATUS register before transmitting is useless in many cases because this bit will be 1 as long as the W5200 is connected to a router, even if there is no Peer.
Is there any way to configure the Retry registers without causing the initial delay in ready to transmit?
Hi,
Before sending data to a peer, need to know the MAC address of peer.
ARP is the process of getting the MAC address. When ARP is failed, No data sends any more.
ARP needs to timeout value(RTR) & Retry count(RCR) because it can’t wait until get the mac.
In addtion, UDP is a connectionless protocol and There is no guarantee that the messages or packets sent would reach at all.
Anyway, Your timeout value seems to be likely to be short.
If without special purpose, you’d better use the default value.
RCR & RTR can be configured regardless of transmittion. Normaly, these registers are configured at start-up time, that is, these can be configured before data transmit. If you don’t need to find a peer at that time, you can configured timeout value with short before data transmit.
As you said, initial delay in transmitting means ARP-processing, am I right?
If you want to no use APR-processing, You should be already known the peer’s MAC address.
If you know the mac address, you can transmit data to the peer without ARP-processing.
For more detail, refer to Sn_CR_SEND_MAC command in datasheet.
Yes, you are probably rigth; it must be the ARP-processing.
However there seems to be a difference in behavior of the W5200 at power up and later:
Once ARP-processing is done, if I disconnect the Peer, the W5200 does not halt the application so I understand that it is not attempting a new ARP process. However, If I connect a new Peer with a different MAC, the W5200 have no problem connecting to it. So why so many attempts at power up?
After some tests I think I undertand the W5200 behavior (please correct me if I’m wrong):
At power up, the W5200 doesn’t have a MAC associated to the Peer IP, so it will attempt to start an ARP process each time a packet is sent (tried to be sent actually). The W5200 will make all the Retry attemtps, which by default takes around 1,6 seconds.
This will happen every time a packet is sent to a Peer_ip which is not associated to a MAC; which, at power up, means that it will happen every time a packet is sent to a Peer which is not connected.
Once the Peer is connected, the ARP process will be done and the Peer_IP will be associated with the MAC IP.
After that, the W5200 doesn’t attempt anymore to start an ARP process with this Peer_IP, no matter if the Peer is connected or not.
If we change the Peer_IP, again the W5200 will attempt to start an ARP process each time the packet is sent to the new IP.
If we change the Peer MAC but not the Peer_IP I don’t know what will happen, but this is a very rare case anyway.
The Peer_IP to MAC assosiation is not saved, so it will be lost at power off and the process will start again at power up.
Hi,
You exactly understood the arp-process of W5200.
Because W5200 doesn’t manage ARP-cache table, ARP processed on power on(reset) and different(new) peer ip.
Here, new peer ip means that the ip address different from the previous ip address. That is, when ip address is changed on every trasmit, ARP process on every transimt.
If APR-process time is overhead, you should manage ARP-cache table and use Sn_CR_SEND_MAC instead of Sn_CR_SEND, as the above said.
