--- title: "W5200 initial delay in transmitting" url: "https://maker.wiznet.io/forum/10035" markdown_url: "https://maker.wiznet.io/forum/10035/md" type: "Forum topic" category: "Ethernet Chips" author: "hzz" created: "2014-03-11T23:43:46+09:00" last_activity: "2017-05-04T08:32:02+09:00" language: "en" views: 776 replies: 7 source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)" --- # W5200 initial delay in transmitting ## Question Asked by hzz on 2014-03-11 in Ethernet Chips. Hi! 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? Kind Regards Hector ## Replies ### Reply 1 by hzz, 2014-03-12 Thanks for your prompt reply! I can discard reason 1. Voltage is stable within ±20mV peak measured with 10us resolution. I will analyze reasons 2 and 3 and post back. Regards Hector ### Reply 2 by hzz, 2014-03-12 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. ### Reply 3 by hzz, 2014-03-13 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. Regards Hector ### Reply 4 by hzz, 2014-03-14 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? ### Reply 5 by hzz, 2014-03-14 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? ### Reply 6 by hzz, 2014-03-16 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. I hope this is useful for others Regards Hector ### Reply 7 by hzz, 2014-03-18 Thanks! It is clear --- Source: https://maker.wiznet.io/forum/10035