Re: [lwip-users] Receive path stuck due to pbuf_alloc returning NULL

[Sergio R. Caprile]

Your scenario is composed of four main pieces of software (to name them
some way). lwIP will handle TCP/IP stuff but will not mess with your
controller. Your driver will. Your driver is not lwIP, it is your
responsibility. I guess you handled it to your vendor and are using
something that is vendor provided.
The third piece of the puzzle is your port, the adaptation layer that
glues lwIP to your OS (or bare metal). Your port is not lwIP, it is your
responsibility. You are using FreeRTOS, that seems to be a working port
and a good one; I don't use it and I can't comment on it.

IRQs, taking care of the controller --> driver
semaphores, locks --> port

when called: frames in, frames out --> lwIP

and then there is your application, using lwIP whithin your port framework.

The only connection between pbuf_alloc() and your controller is that
your driver will use pbuf_alloc to get the memory to put the incoming
frame there. The piece of code that will get the interrupt, handle the
semaphore or whatever, read the frame, store it in the pbuf (the piece
of memory returned by pbuf_alloc()), and keep the controller healthy is
your driver.

You seem to have a problem with the driver not operating correctly on
the chip, or there is some semaphore/mutex/equivalent in your port that
is not properly setup.

You have to at least know whether IRQs are not being generated or not
being accepted. Place a breakpoint on the IRQ handler and see if it
fires and then what happens there. (Of course you will need to provide
some traffic so your controller can receive it.)
If it doesn't, try to find the ones disabling/reenabling it and why that
might fail (race conditions, deadlocks, that stuff).
Welcome to the fascinating world of debugging embedded systems.

There is another possibility, that you are violating the threading rules
somewhere.
Please check it: https://www.nongnu.org/lwip/2_1_x/pitfalls.html