Showing results for 
Search instead for 
Did you mean: 

BUG: CubeMX FreeRTOS projects corrupt memory

Typical user symptom: sprintf with floating point doesn't work or crashes.

I've provided a complete explanation and required fixes here:

To illustrate the crash in minimal test application, I've provided this example project ready to run for a Nucleo 429:

Set breakpoints at:

sysmem.c: on the line with errno = ENOMEM;

main.c, in default task, on line kaboomP1 = malloc(16);

Enjoy the fireworks.

Comments on (one of) the problems are provided in sysmem.c

The fixes are explained in the web page linked above, and illustrated in this corrected minimal project:

It would be great if STM could:

- confirm they understand this set of bugs

- fix them in a prompt release of ST32cubeIDE/CubeMX/etc.

OK, we can dream, right?


Best Regards, Dave


Can someone confirm this was solved by ST? or is better to use Dave's solution??

Associate II

You may want to check out this discussion with Dave. From studying the generated code and the docs, I think the "FreeRTOS strategy #5: deny lock usage from interrupts" might in fact work, and I am experimenting with it, but it is too early for any final conclusion, and I cannot say anything about the other "strategies".

@GMock.1​ - "Might Work" ? Hope is not a strategy...

Sorry I'm too busy at the moment to check out ST's latest attempts.

But given its the same staff that have delivered innumerable failed attempts in past, poor probability of solid results...

Associate II

@Dave Nadler​ As I said, I am evaluating their solution instead of just "hoping" it will work: I have read the documentation, I have studied the generated source code and (to some extent, more to do) followed execution paths on an actual device in the debugger. So far (and for strategy #5 only), I have not seen anything that is not working by design at all (like previous releases) or has bugs in its implementation. I also did not encounter any mysterious crashes (but that does not mean much, as I still need to run long time stabiltiy tests with random mallocs etc). That is what "it might in fact work" means.

It is always easier to prove something wrong than to prove it right. In any case, more people need to have a look at it, otherwise we will never know for sure.

Senior II

I don't understand what is going on here.

As I wrote above, the newlib printf and heap lib which comes with ST Cube IDE (and thus gets generated by Cube MX) is stuff from 1990 and it has been built badly, with mutex protection in the right place but with the mutex calls being empty stubs. This can be fixed but not completely trivially because libc.a (where all this stuff lives) was compiled without the symbols being "weak".

That link to Dave Nadler's site is a zipfile containing the following

_legacyfs_online_stmicro_images_0693W00000dDUrCQAW.pngwhich I cannot understand the relevance of. Most/all of those files have no relevance to this problem.

Chief II

Of course ST couldn't do it without breaking and messing up something...