Re: [lwip-users] LWIP stops responding on Ping and HTTP calls from a browser

[address@hidden]

Kieran Mansley wrote:
> On Fri, 2011-04-22 at 10:52 +0200, Ruben van der Kraan wrote
> > After a boot of the software everything works ok. I can Ping, acces
> > the webserver pages, open the telnet server.
> > But at a point the websever and ping stop working. In wireshark i see
> > my PC sending request to the embedded device
> > a STM32F217 but the stack does not send a respons.
> Such problems almost always turn out to be a bug in the port or
> application where they're violating lwIP's threading constraints,
> resulting in more than one thread active in lwIP at one time,
Explictly written, the limits when not using an OS are:
- make sure lwIP functions are only called from the main loop or from 
*exactly one* interrupt level.
- E.g. when using lwIP from the main loop (which is the most common use 
case, I guess):
   - do *not* feed packets into lwIP from the ethernet RX interrupt,
   - do *not* free TX pbufs from the TX interrupt (pbuf_free())
   - do *not* call timers from interrupt level (e.g. by using a 
hardware timer). Instead, call the timer functions from the main loop. 
If you need to use a hardware timer, use it in polled mode, or let the 
ISR set a flag for the main loop to process timers.
   - the only thing you may from ethernet interrupt is to allocate a 
PBUF_POOL (*not* PBUF_RAM!), copy the received packet into this pbuf and 
put it on a list to feed it into lwIP from the main loop (for DMA, see 
below) (although there are *some* exceptions for experts here, but these 
require more detailed knowledge of lwIP)

For RX-DMA-enabled MACs, you would preallocate as many PBUF_POOL pbufs 
as the MAC has DMA buffers, and set up the buffer descriptors to point 
to the pbuf's payload pointers (for MAC's supporting scatter-gather DMA, 
pbufs may be smaller than the maximum RX size, for MAC's *not* 
supporting scatter-gather DMA, pbuf->next must be NULL).
In the RX interrupt, when you would then put the received data-pbuf on a 
list (responsibility changes from MAC to lwIP), allocate a new PBUF_POOL 
and set up the MAC's DMA buffer descriptors as before.


As to the ethernet packet with type 0x69: since this is not a valid 
EtherType (or is it?), this means either the RX side of your MAC (or 
driver) got corrupted (i.e. there are some bytes missing at the 
beginning of a frame...)

Hope that helps...

Simon