pBuf size and memory allocation.

[Shaun_82]

Background

NUCLEO-H723ZG Board

FreeRTOS + LWIP

Using netcon with netbuf in its own task to receive packets as follows,

IGMP Groups, receiving sACN packets (638 bytes per packet at 5us spacing), each group you join adds a packet, there is a 40ms gap between each burst/set of packets. So,

No. Groups * 5us ------- 40ms gap ------- No Groups * 5us ------ 40ms gap ------

In my receive task I confirm the packet is good and then DMA the needed data into a buffer, I’m using a pin in the routine to go high on entry and then low when processed.

My Issue / Advice

I have the IGMP up and running and can join 14 groups, I’ve had this running for hours without issue, however when I try and add 15/16 groups the system hard faults.

My assumption

I’m running out of spare pBuf for the incoming RX thus the hard fault, I have tried increasing the PBUF_POOL_SIZE from 16 to 20, however the system still hard faults. I suspect this is a memory access / allocation issue.

So,

1. How are the pBuf and netbuf sizes related
2. There are various defines, MEMP_NUM_PBUF, PBUF_POOL_SIZE, do all of these need to increase?
3. Where are the pBuf / netbuf pools allocated as this is not clear in the docs
   1. Heap memory? LWIP heap?
   2. Stack? Who’s stack?
4. What is the “Rx_PoolSection” used for?
5. Number 4 worries me as this has to be placed in RAM2 on the h723 and is 32k in size, would this create a limit on the amount of RX data you can receive?

At this stage I’m just experimenting with how many groups can I join and what sort of throughput I can achieve,

Any help would be much appreciated.

[Shaun_82]

Just in case anyone finds this later.

The pBuf settings in CubeIDE are for the TX and the “Rx_PoolSection” is used for the incoming packet allocation. On the H732 this has to be placed in SRAM1 as 2 is not big enough to hold it. Increasing the size sort of helped and playing with the MPU settings for the pool as well.

Anyway, FreeRTOS + LWIP is a broken mess that I struggled to get working, to enable IGMP you have modify various source / header files with various flags and also add sections of code for the the MAC filtering. There is barely any documentation for this and most of what needed to be done was taken from forum posts over 9 years old, so the port is not maintained.

LWIP appears to also not be thread safe as I kept getting various hard faults, pointing printf to UART3 and using in different threads cause garbage out, great for debugging. 

Your best bet is just to go to Treadx, took an 1hour to set everything up, worked almost instantly and gives you nice tools like TraceX, which shows how the packets and being processed.

25 packets received at 5us spacing, held in buffers and then processed afterwards.