FreeRTOS + LWIP + FatFS loops in “prvIdleTask”

Hi,
I’m using FreeRTOS + LWIP + FatFS to host an embedded webserver on the STM32F765. Directly from startup the application goes into prvIdleTask, after one iteration through each of my 2 tasks. I believe the error is due to the FreeRTOS variables and ucHeap being placed in the SRAM region when building the application (I’m using CMake). If i explicitly build the files in a specific order to make sure the FreeRTOS stuff is placed in DTCM it seems to work fine. Has anyone else experienced the same/have an explanation as to why this might be happening?

PS: The error also only seems to occur when Dcache is enabled, which I have understood is necessary from a performance perspective.

That seems to indicate a cache coherency issue.

Which stuff are you placing in DTCM?

Basically I changed the build order to build all fatfs and freertos source files before lwip to make it work, so since DTCM is 128kB I think most if not all the variables related to freertos are initialized there.

“That seems to indicate a cache coherency issue.”

I don’t really know a lot about cache coherence, would you mind pointing my in any direction on how to solve it perhaps?

I do not think changing the compilation order should have any effect on the placement. We need to narrow down the issue here. Can we remove LWIP and FATFS and just have 2 FreeRTOS tasks and see if those run? If that works, we can add LWIP and FATFS one by one and try to pin down the problem.

I would recommend trying with the cache disabled to see if that changes the behaviour. If it works with the cache disabled then either just changing the run-time characteristics co-incidentally helped, or you can try and narrow down where the cache could cause an issue.

So I’ve managed to dig a little deeper into the issue: I explicitly placed the ethernet buffers in DTCM using “_attribute”, and now atleast I am able to ping the device from my PC. But now it hardfaults when I perform a http request from web browser… It enters the hard fault handler from the clmt_clust() function in ff.c where a pointer with an invalid address is being dereferenced. The culprit seems to be the cltbl attribute of “fp” (which is the pointer to the file system).

I think on the Zynq Ethernet buffers are kept in uncashed memory - probably because both application code and dma access them (two different bus masters).