• State
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 44 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TM4C129XNCZAD: UDP Packet Drop on Tiva C Board

Allaa Kamel
Prodigy 60 points

Part Number: TM4C129XNCZAD

Hello,
I am working with Tiva C TM4C129XNCZAD, TI RTOS and NDK based environment. 
The system I am working with consists of Tiva C based board with Ethernet socket, a software that communicates with the board over UDP. The PC hosting the software is connected via Ethernet cable directly to the board with no switches. The software has a list of around 300 target IP including my board's IP. 
 
There is an issue where UDP packet loss happens on the board side. This loss happens only when some target IPs are disconnected from the network.
Using wireshark, it is observed that there is an excessive stream of ARP packets on the network when the software sends UDP packet to all its targets while they are disconnected except for 1 board. 
If the software has only the connected board IP as target, no UDP packets are dropped. 
 
Related PBM Configurations are as follows:
Global.pktNumFrameBufs = 11;
Global.memRawPageCount = 12;
Global.memRawPageSize = 3200;

Take into consideration that the issue is not related to the packet size since it happens with variable packet length. Also, the issue persists even upon increasing the number of frame buffers "Global.pktNumFrameBufs" to 50.

What is your guidance on resolving this issue?

Thanks,
  • 0
    TI__Mastermind 26465 points
    Hi 
    The issue you are experiencing is a classic network stack exhaustion problem caused by an ARP broadcast storm. When your PC software attempts to communicate with 300 disconnected IP addresses, it floods the wire with ARP requests. Because you have a direct Ethernet cable connection with no switch to isolate or rate-limit traffic, every single one of these broadcast packets (FF:FF:FF:FF:FF:FF) must be processed by your Tiva C board's Ethernet MAC hardware and passed into the NDK stack.  Setup broadcast / multicast UDP with NDK 
    Increasing Global.pktNumFrameBufs alone did not resolve the issue because the bottleneck is likely occurring at either the hardware descriptor level, the individual socket receive buffer level, or due to CPU starvation during stack processing.
    1. Increase EMAC Hardware RX Descriptors
    The Tiva C NIMU (Network Interface Management Unit) driver handles packets via a ring of hardware RX and TX descriptors. By default, TI's driver templates (typically found in your board file like EK_TM4C1294XL.c or the NIMU driver source) set NUM_RX_DESCRIPTORS to a very low number (often 4 or 8).
    • During an ARP flood, the hardware RX queue fills up faster than the NDK's network processing task can fetch them, causing the hardware to drop incoming UDP packets at the physical layer before they even hit the NDK's Packet Buffer Manager (PBM).
    • Fix: Locate your board initialization or NIMU driver file and increase NUM_RX_DESCRIPTORS (and optionally NUM_TX_DESCRIPTORS) to 32 or 64.
    2. Expand individual Socket UDP Receive Limits
    The NDK enforces a default internal memory threshold per socket via CFGITEM_IP_SOCKUDPRXLIMIT, which defaults to only 8192 bytes. If the CPU is briefly delayed processing the massive volume of incoming ARP requests, your application task may not call recvfrom() fast enough. Once the targeted UDP socket reaches this 8KB limit, the stack drops subsequent UDP packets. https://e2e.ti.com/support/processors-group/processors/f/processors-forum/185169/udp-packet-loss?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending)
    • Fix: Increase this limit in your NDK configuration (.cfg file) or dynamically via code before creating the socket:
      c
      uint32_t receiveBufSize = 65536; // Increase to 64KB or higher
CfgAddEntry(hCfg, CFGTAG_IP, CFGITEM_IP_SOCKUDPRXLIMIT, CFG_ADDMODE_UNIQUE, sizeof(uint32_t), (uint8_t *)&receiveBufSize, 0);
      Use code with caution.
    • Alternatively, use setsockopt() with SO_RCVBUF on the active socket. 
    3. Check Task Priorities (Prevent Application Starvation)
    The NDK core stack thread (ti.ndk.config.Global.ndkThreadPri) defaults to a high priority (typically priority level 5 or higher in TI-RTOS). If your UDP application processing task shares the same or a lower priority than the stack task, the incoming wave of ARP packets will completely starve your application loop. The stack will keep consuming packets from the hardware but will choke the UDP socket queue because the application never gets execution time to clear it. 
    https://software-dl.ti.com/simplelink/esd/simplelink_msp432e4_sdk/4.10.00.13/docs/ndk/NDK_API_Reference.html
    • Fix: Ensure your application's UDP receiving task runs at an equal or higher priority than the NDK stack thread, or optimize your receive thread to strictly handle recvfrom() and offload the actual data processing to a lower-priority worker queue.
    4. Enable Hardware Broadcast Filtering (Advanced)
    If modifying buffers and priorities does not fully solve the issue, you can configure the TM4C129x EMAC hardware frame filter to reject broadcast traffic entirely, though caution is required. Dropping all broadcasts will break your board's ability to receive legitimate ARP requests when another device actually tries to look it up.
    • However, if the PC's MAC address is explicitly hardcoded into the board, or if your system design allows for a static ARP configuration on both sides, you can tell the hardware to reject broadcast frames via the EMACFrameFilterSet API using the EMAC_FRMFILTER_PASS_MULTIPERFECT mask rather than allowing all broadcasts through
    Summary Action Plan
    1. Double check your board file to scale up NUM_RX_DESCRIPTORS.
    2. Increase the NDK UDP socket buffer limit (CFGITEM_IP_SOCKUDPRXLIMIT).
    3. Verify TI-RTOS Task priorities to ensure the NDK thread doesn't starve the application https://e2e.ti.com/support/processors-group/processors/f/processors-forum/185169/udp-packet-loss?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending)

    Thanks