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


Status is that it was brought up in the meeting yesterday and decided that it will be handled at least in the STM32CubeIDE context.

The link to your website was added to the ticket to provide additional details of the problem as it is today.

Since this was reported a while ago, this fix has also been added to my STM32CubeIDE patch that fixes other issues with XML generation of .cproject files. 1 hour turnaround and not several months, see how it's done ST?

Hi Dave,

Appreciate the wonderful effort. I guess a lot of developers will be thankful for your solution, me included. I would like to know if there is anything that is device family specific in this solution. The heap management source file to be used mentiones STM32F4 series in it. Any changes to be done for STM32L4?

Also, does it work with CMSIS_RTOSV1 and V2?

Regards and Peace,

Omar Hussain M.

@Omar Hussain M​ - heap_useNewlib is pretty generic so should be OK for L4. NXP ships it for use with their processors and lots of others use it as well. I don't think there are dependencies on CMSIS.

Hope that helps,

Best Regards, Dave

@Markus GIRDLAND​ - Its been more than 3 months since I provided the above fix.

What's happening???


Best Regards, Dave

Latest update I heard is that it was nominated as a fix for 1.2.0, but I don't want to promise that it will be fixed in that version. It's still too early for that.

@Markus GIRDLAND​ - Thanks for the update.

Please, for all our sake, make it clear to your team this is fixed when all these are completed:

  • heap_useNewlib (or equivalent) replaces heap4
  • sbrk provided by STM is suppressed for FreeRTOS projects
  • FreeRTOSconfig.h includes #define configUSE_NEWLIB_REENTRANT 1
  • all STM example projects including FreeRTOS are updated as above
  • copyright notices in heap_useNewlib are respected

Again, all the relevant details are here:


Best Regards, Dave

The ticket links both to this thread as well as your website with explicit instructions to read through the instructions on the website before implementing anything because, and I quote the developer that made the comment:

"There are a few pitfalls that you can end up in if you select one of the pre-defined heap implementations in FreeRTOS."

So hopefully that is clear enough.

Markus and team,

At least, this issue should be covered in UM1722.

This could become a very useful document for beginners and not only.

-- pa

@Markus GIRDLAND​ - Coming up on 5 months now.

Can you please give us an update?

As you must be aware MANY OF YOUR CUSTOMERS continue to be affected by this.


Best Regards, Dave