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

[RSylv.1]

Any news about this problem ?

[Markus GIRDLAND]

Latest update is that it won't be in the upcoming version of CubeIDE. It's still prioritized highly and it's targeted release is the release after the upcoming one.

[aklofas]

What's the reason behind this? As someone who just found this thread today after spending hours tracking down the hard-faulting code that *you* provided in CubeIDE, this seems like crazy talk. Why this isn't pants-on-fire high priority is beyond me...

[Michael B]

Welcome to the **** show. We can look forward to a fix sometime in Q4 2020 I’m guessing based on past experiences.

[Markus GIRDLAND]

As far as I know it's because it's a cross-team solution which slows things down as well as priority issues. Even if it is prioritized highly, much due to me pressing the dev team because of this thread, other things are prioritized higher still.

[Dave Nadler]

@Community member​ - You're being very optimistic...

[MBrow.1]

Haha they must love the smack we give them, I just wish it wasn’t the truth. For all I love the processors themselves, everything else is just terrible. I guess they have just embraced it

[DerekR]

Am I wrong or is this fixed in STM32CubeMX 5.5.0 for STM32CubeIDE generated projects? Calling printf() with the "#define PUTCHAR_PROTOTYPE int __io_putchar(int ch)" macro seems to work before the RTOS scheduler starts and from within a RTOS task.

I ask because I want to implement the same fix to System Workbench projects since these are still broken when generated by CubeMX.

If so, what is the fix for STM32CubeIDE projects so I can port it?

Thanks!

[Dave Nadler]

@DerekR​ - Last I checked this was still not fixed, did you really check???

Specifically, did you read the web page carefully, and verify in your project:

• heap_useNewlib is included (not heap4),
• FreeRTOSconfig.h includes #define configUSE_NEWLIB_REENTRANT 1
• printf of floating point works in a task,
• malloc returns sensible values in a task

@Markus GIRDLAND​ - Any update as to when this will be fixed, in both CubeMX and all FreeRTOS examples from ST?

[DerekR]

Hey Dave!

I have read quite a few of your posts on this forum as well as the FreeRTOS forums and some others. I appreciate your dedication and support to the community and those such as myself.

In the current version of STM32CubeMX (v5.5.0), it generates a STM32CubeIDE project without the following:

• heap_useNewlib.c (It continues to use heap_4.c)
• configUSE_NEWLIB_REENTRANT 1 (Not present in FreeRTOSConfig.h)

I did not test the following:

• printf of floating point values
• malloc return values

My observation of the current STM32CubeIDE generated project:

• _sbrk in sysmem.c is no longer called as breakpoints set in this function are not reached. Instead, the project is generating its own or perhaps using one included in newlib? I verified this by removing the sysmem.c file from the project and the functionality of printf() does not change in that it still works with basic strings (with parameters, ie %s) before the task scheduler is started and from within tasks. I also found that _sbrk is being generated and called before and after removing the sysmem.c file by stepping through the disassembler.
• heap_4.c is still being used, verified with breakpoints

I am currently using:

• STM32Cube_FW_H7_V1.6.0
• STM32CubeIDE v1.2.1 (For testing printf/malloc)
• STM32CubeMX 5.5.0

I still plan to develop with System Workbench for STM32 since it seems more stable and user friendly at the moment.

Few questions:

1. With the above, what could STM have done to make printf work at least somewhat? Projects generated in System Workbench for STM32 still hard fault when calling printf() with parameters such as %s, %d, etc, but they do not in STM32CubeIDE projects.
2. Does using your heap_useNewlib.c and other patches take advantage of the benefits of heap_4.c, specifically in regards to memory fragmentation optimization?
3. I previously migrated from using Keil uVision which uses MicroLIB and never had any of these issues. I can't find the source for MicroLIB, but do you happen to know if it suffers the same problems? If not, how is it managed there? (If you happen to know)

Thanks again!

Derek