Re: [lwip-users] Can serve only short webpages

[JM]

As a test I commented out the periodic timer interrupt handler function which I believe (?) isn't required with simple static IP, no DNS, no packet loss over LAN. Just temporarily to simplify things. It still generates the queue errors.

After initializing lwIP and calling httpd(); I have while(1); and that's all. My ethernet RX interrupt calls low_level_input(). It did also call a function that checks timer values and consequently calls etharp_tmr(), tcp_tmr() etc. but I commented that out too as a test.

The only other interrupt that's still active is for a buffer for debug UART messages. I disabled that too for good measure and no change.

So now the only entry into lwIP is through low_level_input(). I've spent a good deal of time trying to debug this and where I got stuck was in  tcp_receive() where it calls pbuf_clen(), which returns MEMP_NUM_PBUF and that's where the underflow originates. If I look at the pbuf passed into pbuf_clen() it does indeed have all pbufs in existence chained to it. I can't understand where this occurred however.

On Saturday, March 3, 2018, 3:14:22 PM CST, address@hidden <address@hidden> wrote:

On 03.03.2018 16:26, JM wrote:

Hi thanks for the reply. My main loop consists of while(1); only. Only the stack is running on the microcontroller and all interrupts going into lwIP (Ethernet Rx and periodic timer)

So are you sure you enter lwIP functions only from one interrupt priority?
With the webserver serving only internal pages, you might get off with that well, but when adding more 'active' connections (TX initiated from your own code) or external file system, beware of concurrent execution here, even without an OS!

tcp_write: too long queue 65507 (max 50)

tcp_enqueue_flags: too long queue 65507 (max 50)

That very long queue is an obvious problem and I have a feeling if I could track it down that would take care of it.

That very long queue is an underflow. And most of the time this happens, it is because multiple execution contexts are active in core code without locking. Not having an OS does not prevent this from happening, interrupt levels can cause this, too.

Simon

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users