LWIP with STM32 H7 works fine on first 16 exchanges commands, after that commands are queued: why?

[YCHTI.1]

I use LWIP on a STM32H7 custom board.

I send command from a PC using Hercules

Board receives commands and parses them out.

After I sent 16 commands, on the 16th command, pbuf_chain is called. On the first 15 commands tcp_server_handle is called.

I use the example in

https://controllerstech.com/stm32-ethernet-4-tcp-server/ 

I have MEMP_NUM_PBUF set to 16 and MEMP_NUMTCP_SEG set to 16. Tried to increase these parameters, didn’t help.

• First time Isend a command of 7 bytes, Hercules gets response of 12 bytes (from stm32 board, no issue here)
• Then send command CmdA of 102 bytes, Hercules gets response of 12 bytes, no issue here.
• Then send another command CmdB of 102 bytes, Hercules  gets response of 12 bytes, no issue here.
• Send command 7 bytes, Hercules Hercules gets response of 12 bytes
• Then send command CmdA of 102 bytes, Hercules gets response of 12 bytes
• …

15)  Then send command CmdA of 102 bytes, Hercules gets response of 12 bytes, no issue here.

16) send command CmdB of 102 bytes, STM32 does not respond but command is put in a chain (pbuf_chain is called in tp_server_recv)

I attached LWIP key settings….

Why the 16th command is queued in the chain and not processed.

thanks

[STea]

Hello @YCHTI.1 ,

It sounds like you're encountering an issue with the buffer management in LWIP on your STM32H7 custom board. The fact that the 16th command is being queued in a chain (pbuf_chain) rather than being processed immediately suggests that there might be a resource exhaustion or a configuration issue.

Here are some steps and considerations to help diagnose and potentially resolve the issue:

- Check Memory Pool Configuration and ensure that your memory pool settings are adequate for your use case. You've mentioned MEMP_NUM_PBUF and MEMP_NUM_TCP_SEG, but there are other relevant settings as well:

• PBUF_POOL_SIZE: This defines the number of buffers in the pbuf pool. If this is too low, you might run out of pbufs.
• TCP_SND_QUEUELEN: This defines the number of TCP segments that can be queued for transmission. If this is too low, you might run out of space to queue segments.
• TCP_WND: This defines the size of the TCP window. If this is too small, it might limit the amount of data that can be in-flight.

- Try increasing the sizes of the relevant buffers. For example:

#define MEMP_NUM_PBUF 32
#define MEMP_NUM_TCP_SEG 32
#define PBUF_POOL_SIZE 32
#define TCP_SND_QUEUELEN 32
#define TCP_WND (4 * TCP_MSS)

-Ensure that you are properly freeing pbufs after processing them. Memory leaks can quickly exhaust available buffers.
Regards