TCP PCB corruption in LwIP with FreeRTOS and STM32F429I

[Michal Golebiowski]

Posted on June 09, 2017 at 08:20

Hello, I have continuously issues with establishing stable netconn web server with STM32F429+FreeRTOS+LwIP 2.0 from CubeF4.

The page have AJAX code whos asking device for data (aprox. 600b) for every second.

After couple of hours (aprox. 10h) or couple fast refreshes of the page (F5) the whole OS hangs in the same place as

https://groups.google.com/forum/♯!topic/osdeve_mirror_tcpip_lwip/UOMYcM5aws4

  <- here. I am using ST's ethernetif.c file and port.

My webpage has more (and bigger) files, about ~50kb but files are stored in SDRAM and web server is really similar to this provided by ST in Cube.

I have no idea where to look for problem - corruption of the memory makes no sense as I am using high level API and I'm not touching mem management. 

Best Regards

,

Michal Golebiowski

#lwip #freertos #ethernet #cube

[AvaTar]

Posted on June 09, 2017 at 09:39

I have only very superficial experience with STM32 IoT devices, but it looks suspiciously like a performance issue.

Seems your device is overwhelmed in higher network load conditions - a problem it shares with many other IoT devices from several vendors ...

You could try a controlled network environment, increase the network load, and monitor core load meanwhile.

[Michal Golebiowski]

Posted on June 09, 2017 at 10:49

I tried using separate router only for a device and my computer and also Point2Point connection there was the same issue. We tested load of the processor and there is max 50% and most of the time it is idle.

Maybe the issue is connected to size of files, and chunks that are sent to browser by netconn_write() but I don't have hard evidences yet, I am testing this right now.

Best Regards,

Michal Golebiowski

[AvaTar]

Posted on June 09, 2017 at 11:52

We tested load of the processor and there is max 50% and most of the time it is idle.

As a saying goes 'The pond was only two feet deep at average, but even so the cow drowned.'

The overload might happen with your interrupts, and interrupt processing time, while it remains mainly idle before and/or afterwards.

If packets arrive faster then the STM32 can process them (no problem for ethernet...), you will loose data, and possibly have corruption.