W5500 executing your Ethernet code for DHCP - Why delay required

Question

Testing a W5500 io module and have a question with W5500 behavior in your DHCP code. After DHCP is initialized it enters function DHCP_Run() where is opens a UDP socket and attempts to parse a DHCP Msg - of which there is none since DHCP is just starting. Then it call function to send a DHCP Discovery message. The function builds the packet and issues a SEND to the W5500. This is where my question comes in - if I send the Discovery packet to the W5500 as written it fails to put any msg on the wire (validated with wireshark). If I place a delay of 500ms prior to the send then all works as expected. I do NOT to just put in a delay to make it work - I'd like to know why. I thought the W5500 might have a busy flag or something that could be tested. The information I found on the web suggested getSn_SR(socket#). I tried that both before and after the delay expecting a different return indicating busy but both returned 0x22. What is happening in the W5500 that would required that delay and is there a way to test and NOT use a delay inorder for DHCP to complete? Thanks. Your AI reply is just putting out common causes without really addressing the issue. All the code is from Wiznet - your W5500.c and DHCP code. This is a terrible forum if only an AI is expected to reply and then sends you to a different if the AI response did not address the issue.

Grace_Koo · Answer

Hi jhinkle . Thank you for pointing this out. Regarding your original question about Sn_SR, Sn_SR == SOCK_UDP (0x22) only indicates that the socket has entered UDP mode. It is not a busy/ready indicator for the first transmit, and it does not by itself guarantee that the first DHCP DISCOVER will be transmitted immediately after socket open. So seeing the same 0x22 value before and after the delay is not unexpected. For checking whether a transmit operation actually completed, Sn_IR is generally more relevant than Sn_SR, because Sn_IR reflects the SEND result path such as SEND_OK or TIMEOUT. However, after reviewing the ioLibrary code, sendto() already appears to perform its normal SEND completion handling internally. So this does not look like a simple case of missing Sn_IR checking inside sendto(). At this point, what looks more important is the sequence around the first DHCP transmit after socket open. In the current flow, the socket may be opened and the first DHCP DISCOVER may follow very soon afterward, so we will review whether this path needs any improvement. If you prefer not to modify the ioLibrary files directly, a practical workaround for now would be to delay or defer the first DHCP processing in the user application code. For example: do not start DHCP immediately after initialization, start the first DHCP_run() on a later main-loop cycle or timer tick, or add a short delay before the first DHCP attempt