2025-04-30 3:36 AM
Dear STM32 Community,
I'm currently working on a bare-metal project with the STM32H723VG using the LwIP stack. I've implemented a TCP Echo Server based on the examples provided in the STM32Cube repository.
The application works as expected when I open a new socket connection from my PC for each request—i.e., I send a message, receive the correct 193-byte response, and then close the socket.
However, if I maintain a persistent socket connection and send multiple messages (without closing the connection), I begin to encounter an issue: after approximately 30 successful requests, the server starts responding with only partial data—typically between 5 and 30 bytes instead of the full 193 bytes. If I then close and reopen the socket, the server resumes responding correctly for another 30 or so requests.
I've verified that socket creation and teardown are functioning correctly on both the client and server sides. This behavior seems to suggest an issue related to buffer management or resource exhaustion within the LwIP stack.
Could this be related to memory fragmentation or improper handling of pbufs or netconns? Or possibly a configuration issue in my lwipopts.h file?
Here are some key settings from my lwipopts.h:
#define SYS_LIGHTWEIGHT_PROT 0
#define NO_SYS 1
#define MEM_ALIGNMENT 4
#define MEM_SIZE (15*1024)
#define LWIP_RAM_HEAP_POINTER (0x30004000)
#define MEMP_NUM_TCP_PCB 20
#define MEMP_NUM_TCP_SEG TCP_SND_QUEUELEN
#define PBUF_POOL_BUFSIZE 1536
#define LWIP_SUPPORT_CUSTOM_PBUF 1
#define TCP_MSS (1500 - 40)
#define TCP_SND_BUF (4*TCP_MSS)
#define TCP_WND (4*TCP_MSS)
#define LWIP_ICMP 1
Solved! Go to Solution.
2025-05-02 1:03 AM
I found the root cause of the problem. In my receive handler, I was incorrectly freeing only part of the received packet - specifically, I freed memory corresponding to the length of the message I processed, not the entire pbuf chain.
2025-05-02 1:03 AM
I found the root cause of the problem. In my receive handler, I was incorrectly freeing only part of the received packet - specifically, I freed memory corresponding to the length of the message I processed, not the entire pbuf chain.