EK-TM4C1294XL: UDP sendto issue on startup

Hi,

  Sorry, I'm not really sure what is the problem. Reading NDK reference guide, the error code indicates memory allocation failure. 

Reading the sendto description further,  https://pubs.opengroup.org/onlinepubs/009604499/functions/sendto.html  it may be that If space is not available at the sending socket to hold the message to be transmitted and the socket file descriptor does not have O_NONBLOCK set, sendto() shall block until space is available. If space is not available at the sending socket to hold the message to be transmitted and the socket file descriptor does have O_NONBLOCK set, sendto() shall fail. Can you find out if you are in blocking mode or non-blocking mode? Can you change to blocking mode? You can use getsockopt() to get the value of a socket option and setsocketopt() to set the value of a socket option parameter. 

Hi Charles,

Thanks for your reply. It seems blocking is on by default, which I verified using getsockopt() as per your suggestion.

Any other ideas?

Hi,

  I found the below two threads with similar problem as reported by you but I'm not sure if the solution is applicable to you. Can you please take a look?

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/601850/rtos-dk-tm4c129x-need-memory-for-ndk-as-in-makinghttpserver-settings-ignored-by-xgconf?tisearch=e2e-sitesearch&keymatch=ENOBUFS#

https://e2e.ti.com/e2eprivate/ficosa/ficosa-sv/f/ficosa-sv-jacinto-forum/1151274/sendto-returns-enobufs/4327024?tisearch=e2e-sitesearch&keymatch=ENOBUFS#4327024

Hi Charles,

I read your first link, which appears to point to a memory problem? Since my issue seems to be temporary, I'm not sure this is the right direction.

I've set my ethernet send task size to 1024, and my packets are no more than 20 bytes.

The task is using a mailbox, a shared socket, and sendto and that's about it. ROV Classic is reporting stackPeak of 504 and heapMem largestFreeSize of 0x2e78. This seemed to be enough evidence to me it wasn't a memory issue but your thoughts are welcome.

I can't open the 2nd link unfortunately.

Hi Sasha,

  The second thread is an internal thread and I didn't realize that. I copy the entire thread chain to the word document. This thread also has ENOBUFS flag. 

What do you mean by shared socket? Does the enet_udpecho_client_tirtos work for you? I'm not sure what is your application requiring you to keep sending data in a while loop without some form of synchronization between receiving certain events and sending out data. Without synchronization, your only active task is in a while loop keep sending data that I think can lead to overflowing the buffer. 

Sendto Returns ENOBUFS.docx

Hi Charles,

The internal thread seems to present a few configuration changes that might help if this is indeed a memory issue, I will try those and get back to you.

As for the shared socket, I am sharing the socket between a receive and transmit task using fdShare. As I said, I'm using a modified version of the example project, I've deviated from it by a fair margin. Also, I'm not sending data in an infinite while loop, I'm sending it periodically (every 200ms).

Hi Sasha,

 I thought at the beginning of the post you said if you add a delay of 200ms then there is no issue. Do you mean to reduce the delay further? Can you tell at what min delay that you can successfully transmit the data?