Lwip tcp stack is locking after 2-3 days of working

[mustafa23]

Posted on September 02, 2015 at 15:20

LWIP stack is lockingup about every 48-60 hours, with a casually polling ModbusTCP connection (~ 1000 ms between polls).It requires apower cycle of our equipment to restore the operation of the stack.i use codes generated from cubemx FW.F4.1.8.0The test board is STM32 Discovery board + STM32F4DIS-BBRegadars?

[Tesla DeLorean]

Posted on September 02, 2015 at 18:14

Cube just provides a starting framework, you'll need to add error recovery and retry logic if the hardware or software get into an unworkable condition. You'll need to analyze what state it gets into when it fails, so look at memory and ethernet MAC/PHY registers, etc to understand why it stopped working.

[mustafa23]

Posted on September 03, 2015 at 11:25

Hello clive1,

Problem occurs after 2-3 days of working so i am not able to debug when problem stars. i need a idea to debug such a caseAre there a way to resetting lwip stack without resetting the mcu?thanks

[bobdeschambault9]

Posted on September 08, 2015 at 19:56

Hi,

Are you using LwIP v1.4.1 sources or using the ''master-branch''?  We have found that the latest code exhibits this behavior but when we use the official v1.4.1 sources, the problem does not occur.

[mustafa23]

Posted on October 03, 2015 at 15:05

Hello Clive1,

i could not find a solutions for problem of stopping eth driver.Could you send me a example project with ethernet Lwip stack for STM32F407 that you are sure about the project ethernet communications doesn't hangs after 3-4 days of working.Best Regards.

[Tesla DeLorean]

Posted on October 03, 2015 at 19:11

I don't have enough resources to make those kinds of commitments to your project, you will need to discuss amongst your colleagues how to move forward.

When issues occur over a long time frame it helps to provide an interactive console for your project so you can probe memory and registers, and understand internal states and conditions. You can also output logging and diagnostic information during the runs, but you have to add such code, and think about the hardware and what pieces of data will be useful to diagnose the problem, or rule out specific causes so you can focus on where the real problems lie.