BUG: CubeMX FreeRTOS projects corrupt memory

[Dave Nadler]

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

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

http://www.nadler.com/embedded/newlibAndFreeRTOS.html

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

http://www.nadler.com/embedded/20190804_STM_malloc-Kaboom_demo.zip

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:

http://www.nadler.com/embedded/20191115_malloc-Kaboom_fixed.zip

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?

Thanks,

Best Regards, Dave

[BCama.1]

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

[GMock.1]

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".

[Dave Nadler]

@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...

[GMock.1]

@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.

[PHolt.1]

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

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

[Piranha]

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

https://community.st.com/t5/stm32cubemx-mcu/cubemx-generated-threadsafe-stm32-lock-h-potential-bug/td-p/77220