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

[Markus GIRDLAND]

I can't speak for CubeMX and the ST examples as that's not my area, I'm in the CubeIDE team. However, we're trying out different solutions to solve as much as possible in a CubeIDE perspective in the meantime but there are still debates about exactly what that would look like.

[DerekR]

Markus,

So are you saying that the latest version of CubeIDE generated projects still have this issue when using FreeRTOS?

If so, or if you don't know since you are not on the CubeMX team, what is your suggested solution for using FreeRTOS with CubeIDE?

Thanks

[DerekR]

Just wanted to provide an update for those who use System Workbench for STM32 (SW4STM32). Dave's patches work flawlessly without any modifications to the generated linker files using a very small FreeRTOS application. No more hard faults! I will update this post if I run into any issues.

[Dave Nadler]

Thanks Derek @DerekR​. I do try to help, though the poor vendor responsiveness and crap quality of infrequent vendor responses is extremely discouraging.

A few points to consider:

• IIRC heap_4.c is a bit more primitive than newlib's heap manager I replaced it with
• I have no idea why you'd get hard fault when calling printf() with parameters such as %s, %d, except inadequate task stack space.
• I can't find the source for MicroLIB - um, then don't use it, or you'll inevitably get bit in the ****...
• you really need to test printf of floating point values and malloc return-value sanity
• I don't know what other sbrk/_sbrk you might be using, but track it down and check it carefully!

Hope that helps,

Best Regards, Dave

PS: @Camilo LEMOS​ ​ - please note...

[DerekR]

@Markus GIRDLAND​ I am currently using Dave Nadler's patches with no issue. Can you confirm when the STM32CubeIDE team will update it with "official" patches to support thread-safe operation with FreeRTOS? I am asking for future reference for myself and colleagues who may be using this IDE in the future.

Thanks,

Derek

[Markus GIRDLAND]

I can confirm that we are working on a way to make it thread safe by default but there are differing opinions on how it will be achieved. Not everyone is agreed that this is the way to do it so I believe there's some discussions about what solution is to be used.

Also, there's some team-synchronization needed as the generated code would need to be thread safe which is in the MX teams corner but there are still some things we are working on in the IDE team to speed things up.

[GMG]

@Markus GIRDLAND​ follow the advice of @Dave Nadler​ and make a temporary patch! I wasted two days for your poor product! I created a project (STM32CubeIDE Version: 1.3.1 Build: 6291_20200406_0752) for STM32H7 (Lib version 1.7.0) with only RTOS and USB CDC and the USB doesn't work, no one line of my code only auto generated code and doesn't work! Incredible that you want to have a product that generate wrong code without advise users of that! Make a temporary path or remove the functionality, you and your team make people crazy! Also CubeIDE configurator have many many problems with freertos enabled, if you define a TIM7 for RTOS and you use other timers project will be corrupted and every time you change something you have to configure again timers! Also many other issues that I can't understand are happening. If many people have a problem and wast time with your tools many people are encouraged to choose a new brand for future projects. I hope in a very short patch for many bugs.

Regards

[Dave Nadler]

@Markus GIRDLAND​ , @Camilo LEMOS​ - Please remove the following buggy post from ST:

https://community.st.com/s/question/0D50X0000CBmXufSQF/newlibmalloc-locking-mechanism-to-be-threadsafe

For heaven's sake don't post even more buggy code! Really Now!

How much do you want to infuriate customers??

[chaaalyy]

Any news or updates about this ??

[chaaalyy]

Not just in USB CDC ... Also with USB MSC there´s no chance... Meanwhile i believe, these "bugs" are built in intentionally to prevent "small" people from using expensive software for free. Behind the curtains and for big players (automotive and so on) of course there is support and of course there are ready to use solutions and fixes, already built in a stable version.