TM4C129ENCZAD: UDP recvfrom() stops working after some time

Hi Mitch,

  If EWOULDBLOCK is returned, it means the socket is specified as non-blocking, or the timeout has expired. The recvfrom() is normally a blocking API. How did you make it non-blocking? Are you using setsockopt() to configure the timeout as zero or a very short timeout that causes the timeout to expire before the PC sends its packets? If you use setsocketopt to configure for short timeout value, can you increase and see if it makes a difference?

Hi Charles,

We use setsockopt() to set a 1 microsecond receive timeout:

            // set timeout to 1us
            struct timeval timeout;
            timeout.tv_sec = 0;
            timeout.tv_usec = 1;
            if(setsockopt(m_udp_sockets[arry_idx].handle, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout)) < 0)
            {
                arry_idx = ERROR_FAIL_U8;
                PRINTFD(TPRINTF_LEVEL_NETWORK | TPRINTF_LEVEL_ERROR, ETHERNET_SET_UDP_SOCKET_OPTION_FAILED, false,
                        "Error - set Etherent UDP rcv timeout fail. code = %d\n", call_fdError());
            }

And we then call recvfrom() in a loop to process incoming messages from the UDP socket.  Next time I am in the office I will increase the timeout to see if that helps.

Thanks,

Mitch

Hi Charles,

I increased the timeout from 1 microsecond to 10 milliseconds and still have the issue:

// set timeout to 1us
struct timeval timeout;
timeout.tv_sec = 0;
timeout.tv_usec = 10000;
if(setsockopt(m_udp_sockets[arry_idx].handle, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout)) < 0)
{
    arry_idx = ERROR_FAIL_U8;
    PRINTFD(TPRINTF_LEVEL_NETWORK | TPRINTF_LEVEL_ERROR, ETHERNET_SET_UDP_SOCKET_OPTION_FAILED, false,
            "Error - set Etherent UDP rcv timeout fail. code = %d\n", call_fdError());
}

recvfrom() is always returning EWOULDBLOCK after a certain point.

Any more ideas would be appreciated.

Thanks, Mitch

Hi Mitch,

  For experiment purpose, what if you keep the recvfrom() in blocking mode? Can you also clarify if your MCU is the client or the server? 

Hi Charles,

I changed the code so that the UDP socket is blocking, and still have the same issue.  It works fine for a minute or 2 and recvfrom() is reading 55 bytes from the socket whenever our PC tool sends a message to the device.  But after a couple of minutes, the recvfrom() call just keeps blocking and doesn't return when the PC tool sends a message to the device.

As for whether the MCU is the client or server, I would say the UDP port is acting like a server.  The PC tool sends a message to the device using UDP, and the device responds with some information about itself.

Please let me know if you want me to try any more tests.

Thanks, Mitch!

Hi Mitch,

  There is a couple of things I'd like you to try.

  1. Can you use the ROV to find out if you have any stack overflow or issues with the memory like the heap? When you increase the task stack and system heap, does it make a difference?

  2. There is Udp_echo example provided by the TI-RTOS. You can download it from Resource Explorer. Not sure you have run this example before. Will you have the same issue running this example if your PC sends the broadcast requests like before? This example has the recvfrom() as blocking. Try with the blocking first and you can modify it to change the timeout period using setsockopt later.

  3. Can you try both the XDCtool 3.32.00.06 and TI-RTOS 2.16.00.08 if you are currently using a higher version? I want to make sure if the issue is related to TI-RTOS 1887 shown in the release note for TivaC 2.16.01.14 in .

  4. Let's try the above three first before we venture to the next one which is the TIDRIVERS 1579 shown in the above known issues page.