I think that I answered that question:
When a correct packet is received using zero-copy, the ownership will be transferred from DMA to the IP-task. At the same time, a new buffer is allocated and assigned to DMA.
So when you pause the application, you may see packets that were rejected, because they have a “wrong” frame-type. They are still owned by DMA.
(
In earlier versions of BufferAllocation_1.c I had registered a name to each buffer, so I could see where a problem had started,
Buffer allocation needs some discipline: we must always make sure that a buffer is owned by a single instance: NetworkInterface DMA, IP-task reception, IP-task transmission, etc. and make sure that every buffer will be released when ready.
)
Back to your question:
I’m having an issue with network buffers getting hung up
What do you mean with buffer getting hung up? Does pxGetNetworkBufferWithDescriptor() return NULL?
In that case you could add a new parameter to pxGetNetworkBufferWithDescriptor() to indicated the location where it was created, e.g. FreeRTOS_TCP_Transmission.c:683.
I work very often with STM32Fxx, and I have not seen problems with buffer allocation.
I just tested with the latest FreeRTOS+TCP (V4.2.2), but the NetworkInterface uses the Legacy, because STM32\Drivers\F7 does not compile.