#1 StartGuardLock Mutex and external Memory

[Daniel Schramm]

Hello,

thanks for your relly good library.
I currently use it in 2 projects. In both projects the FreeRTOS Heap is external memory.

The first is an stm32 with external SRAM which is initialized before main() and everything is perfect.
But in the second project I need SDRAM initialized early in main() and run into trouble with the freertos memory management. Rewriting the code to use a static pointer to mutex and allocating it in the first call of the Thread contructor seems to solve the issue.
I attached my experiments and will update this issue after running some tests.
Please review the Idea since it could help whereever custom memory management for FreeRTOS is used.

Best regards,

Daniel Schramm

[Daniel Schramm]

Had still some isues. See changes attached.
Now still one exception exists for a working release. The task object cannot be initiated from main(), which causes a hard fault.
If it's created within another thread it works well.
Perhaps you have an idea how to solve this.

Thanks,

Daniel Schramm

[Michael Becker]

Hi Daniel,

FreeRTOS, the FreeRTOS C++ wrappers, as well as with just about every other C or C++ library expects RAM to be initialized before the initial entry point into main(). If this isn't happening, then it's a violation of the standards.

That being said, could you attach sample main.cpp code that exhibits the problem, with comments as to where you are initializing both global as well as heap memory if it's non-standard? I'd like to see the code that causes the failure before looking at any changes to cthread.cpp / thread.hpp, so I have some context.

Thanks!
-Mike

[Daniel Schramm]

Thanks for the answer.
I'm still triying to track down the issue in the STM32F7 - Cortex M7 - 32F746GDISCOVERY.
With a selfmade STM32F4 - Cortex M4 boards everything is workling perfectly.
I already changed the code to do initialisation before main and use your unmodified code again - but there are happening stange things during task creation. Sometimes tasks are not created and sometimes creation results in hard fault.
I will come back later with code examples when I can reproduce the issues repeateable.

Thanks,
Daniel

[Daniel Schramm]

Hello,

It took a long time ans a chat with ST specialists to track down the hard faults in SD-RAM with the Cortex M7.
The reason for all the issues is the cache configuration ot the processor which must not be activated on the stack.

So we can consider one part of this issue as closed.
But I would like to catch up with the Idea of late memory assignment which fully matches the design ideas of C++ or at least the STL as the concept of Allocators shows.
Also including an STL Allocator to your source tree (see attachment) could also be interesing for others.
In my project I use malloc/free for internal SRAM and pvPortMalloc/vPortFree for external memory.
So the std::allocator uses internal sram and the attached allocator uses the FreeRTOS heap.

Thanks,

Daniel