socket.c sendto() ignores SOCK_IO_NONBLOCK flag?

Question

Hi, I’m using the io6library for the W6100 is all working well so far except for the sendto() function in socket.c seems to block even though I have set SOCK_IO_NONBLOCK. I’m running DHCPv4_run(), which works and gets an IP address, but it blocks in the function check_DHCPv4_leasedIP() when calling sendto(). I’ve tracked it down to this section near the end of sendto(): while( 1 ) { tmp = getSn_IR( sn ); if( tmp & Sn_IR_SENDOK ) { setSn_IRCLR( sn, Sn_IR_SENDOK ); break; } else if( tmp & Sn_IR_TIMEOUT ) { setSn_IRCLR( sn, Sn_IR_TIMEOUT ); return SOCKERR_TIMEOUT; } } It waits in this loop until the timeout occurs (about 1.5 seconds) and then returns SOCKERR_TIMEOUT. I have configured the socket using SOCK_IO_NONBLOCK, so why does it block? I changed socket(DHCPV4_SOCKET, Sn_MR_UDP, DHCPV4_CLIENT_PORT, 0x00); to socket(DHCPV4_SOCKET, Sn_MR_UDP, DHCPV4_CLIENT_PORT, SOCK_IO_NONBLOCK); Any help would be appreciated! Thanks, Gareth

Eugeny · Answer

The code is correct from WIZnet chip workflow sequence, but you raised interesting issue. Under normal circumstances data sending is performed very quickly, here we have the issue with sending timing out. Can you please check what arguments you supply to send()? Because if send command does not complete using interrupts usually means misconfiguration (something wrong in registers, specific interrupts are disabled in Sn_IMR) or hardware issue.

Eugeny · Answer

ghorth: So in this case there should be no reply - hence the timeout? No. In the code you provided the chip (and software) is doing sending only. It is SEND command which is not being performed properly, there’s no receive involved. ghorth: I’m not sure what you mean about interrupts. The code you cited checks for two bits - Sn_IR_SENDOK and Sn_IR_TIMEOUT, and blocks until each of them gets set. Normally SENDOK is the first, informing software that data was sent. In your case it is TIMEOUT, and it means either sending is experiences the problems or Sn_IMR register for this socket has bit SENDOK reset (and therefore SENDOK interrupt does not happen, while SEND command is completed properly). Further research is needed on what value Sn_IMR (as well as IMR in common register block) are having when problem occurs. ghorth: Should I be using hardware interrupts to a pin on my micro? No, no need for hardware changes, a least for this problem. No MCU IST needed, you have code which, for some reason, does not work as expected, and we must sort it out. ghorth: Crucially though, it would not block, Normally the code you provided does NOT block, sending is performer relatively quickly. In your case something prohibits sending.