LwIP doesn't receive messages after a while

[andreatoscan9]

Posted on March 25, 2016 at 17:06

Hallo,

I'm developing on a board based on STM32F407 and FreeRTOS, FatFS, and LwIP. The code is generated by Cube 4.13.

The problem is that during a test with a continuous ping (-f) the board doesn't receive messages after a while. Some times it is possible to have a default header interrupt due to a illegal access memory done by alloc or free mempool functions.

In my opinion it is a matter of LwIP configuration, but I don't understand exactly what.

Does someone have a similar problem?

Any idea to debug and solve it?

Thanks.   

[Walid FTITI_O]

Posted on March 30, 2016 at 18:01

Hi toscan.andrea,

I suggest you to start from the lwIP examples under STM32cubeF4 package to compare with your project.

Examples under this path: STM32Cube_FW_F4_V1.11.0\Projects\STM324xG_EVAL\Applications\LwIP

For the CubeMx side, you can refer

to the paragraph ''B.3.6 LwIP'' in the

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00104712.pdf

.

For more details, you can refer to

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM00103685.pdf

“Developing applications on STM32Cube with LwIP TCP/IP stack “

that can help you in developing you application.

-Hannibal-

Hallo,

I'm developing on a board based on STM32F407 and FreeRTOS, FatFS, and LwIP. The code is generated by Cube 4.13.

The problem is that during a test with a continuous ping (-f) the board doesn't receive messages after a while. Some times it is possible to have a default header interrupt due to a illegal access memory done by alloc or free mempool functions.

In my opinion it is a matter of LwIP configuration, but I don't understand exactly what.

Does someone have a similar problem?

Any idea to debug and solve it?

Thanks.   

[AvaTar]

Posted on March 31, 2016 at 08:06

> Any idea to debug and solve it?

 

Instrumenting your code according to your requirements. Perhaps add GPIO toggles to visualize entry/exit of relevant functions (via a scope).

Set up a separate network segment, with one other network participant. This could be a PC with network testing software, which allows you to send defined packages at defined times/rates. Then, test your board while gradually increasing the network load. It should then be no problem to consistently trigger your problem.

Debugging in a real-world networks with unpredictable traffic is like fishing in muddy waters.