LWIP freeRTOS and BSD Sockets

[FMarr.2]

Hi,

I have started from a project by Adam Berlinger.

I have two UDP sockets, one receiving data max 500 bytes/s one sending data 200 bytes every 5 seconds and one TCPIP sending 4K every 20 ms.

Netconn Api I have no problem. With BSD sockets, If I work receiving data from UDP socket from a single or maximum 2 clients the UDP socket works well, but if I have 3 or more clients sending data on that UDP port, after a while the sockets returns no data even if they are.

If I ask to print stat at display everything seems to be correct and as I imagined there is full of available memory and of all, no error at UDP level.

Do you have any idea on what is happening? I used the same code on LWIP 1.1 on another microcontroller slower with less memory but no dma, and everything worked very well.

Best Regards 

[STackPointer64]

Hello @FMarr.2, and welcome to ST community!

What you’re experiencing is a known behavior on STM32 devices using lwIP where the Netconn API works fine but the BSD sockets UDP receive seems to stall when multiple clients are connected. This usually happens because of resource limits and how the socket layer manages buffering, rather than a simple "out of memory" error.

Here’s why: the BSD socket API is built on top of the Netconn API and adds an extra sequential layer using mailboxes and queues to handle data. When you have multiple UDP clients plus a continuous TCP stream (like your 4 kB every 20 ms), these mailboxes and buffer pools can get overwhelmed. This causes stalls or dropped packets even if overall memory looks fine. The Netconn API bypasses some of this, so it remains stable under the same load.

To diagnose and fix this, here are some detailed steps and tests you can try:

• Lower TCP Throughput: Temporarily reduce your TCP stream rate or send smaller chunks. If UDP becomes stable with many clients, it's a strong sign that memory or mailbox limits in lwIP are causing the issue.

• Prompt Socket Reading: Make sure your application reads data from all sockets quickly. Delays cause mailboxes and buffers to fill up, which leads to stalls.

• Enable Full lwIP Statistics:
  Turn on stats for pbuf, memp, udp, ip, and link. Watch for any pools hitting their maximum configured size or showing packet drops during your multi-client UDP plus TCP traffic. For example, if PBUF_POOL_SIZE or MEMP_NUM_UDP_PCB is saturated, lwIP can’t allocate enough buffers, causing dropped packets.

• Tune lwIP Memory Pools:
  Increase these settings in your lwipopts.h:

  • PBUF_POOL_SIZE (number of packet buffers)
  • MEMP_NUM_PBUF (buffers for copyless transmission)
  • MEMP_NUM_UDP_PCB (number of UDP "connections")
    Also increase MEM_SIZE if you raise these values to provide enough heap.

• Adjust TCP Buffers:
  Check your TCP_SND_BUF, TCP_WND, and TCP_MSS values. Large TCP buffers can consume lots of memory, starving UDP buffers. You might need to reduce TCP buffer sizes slightly while keeping throughput acceptable.

• Verify Ethernet DMA Buffer Placement:
  On STM32H7, ensure Ethernet DMA descriptors and RX/TX buffers are in DMA-accessible SRAM (like D2 SRAM), not DTCM. Incorrect placement can cause packet loss or stalls under load.

• Compare Netconn vs BSD Socket Behavior:
  Test both APIs with the same lwIP configuration. If Netconn works fine while BSD sockets stall, it confirms that the socket layer’s mailboxes and buffering are the bottleneck.

By following these steps, I think you can identify exactly which resources are limiting your system and tune lwIP accordingly to support your multi-client UDP and TCP workload reliably.

Best regards,