[lwip-users] Embedded lwIP application stops working after 4-5 days

[peter]

Hi

I am working on an embedded application in which I use lwIP to 
periodically send HTTP packets to a webserver (as TCP packets). It works 
fine for 4-5 days and then suddenly stops working. I have enabled lwIP 
stats in my lwipopts.h and it is outputting lwIP status to the UART. I 
captured this output to a file and also used Wireshark to capture the 
Ethernet traffic.

In the lwIP log file, I see that around the time when it stops working, 
the fields "max" and "err" in the MEM UDP_PCB section contains the 
number 4294967295 (2^32 - 1) which is strange, since these fields are 0, 
1 or 2 in the long period where there is no problems. This indicates to 
me that some kind of overflow is happening in the memory allocated to 
lwIP? Or could it be something else?

In the Wireshark log, I can see that after my application is doing a 
HTTP POST, it usually gets a HTTP OK from the server as it is supposed 
to do. When things go wrong, this does not happen. After that, the 
router can no longer detect the microcontroller.

I originally posted a similar question on the TI-E2E Community since I 
am using the Texas Instruments TM4C129XL LaunchPad Evaluation Kit (which 
is an ARM Cortex M4F based microcontroller with Ethernet PHY and other 
stuff on board). I got some responses to my question -- including the 
suggestion that I turn off UDP in lwipopts.h. I cannot do that, since I 
am using DHCP.

This thread 
(http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/519748/1892060#1892060) 
appears to be dead now, which is why I am writing to this mailing list.

By the way, I am using lwip-1.4.1 as supplied with TivaWare (TI's C 
library for the TM4C-series microcontrollers).

So, I am hoping that an experienced lwIP user or lwIP developer can 
explain the meaning of "max" and "err" in the MEM UDP_PCB section and 
what could cause the strange values in these fields. Hopefully that 
could lead to a solution.

Any help is very appreciated - thanks in advance :-)

Regards,
Peter Haagerup.