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]

We are aware as this has always been an issue in TrueSTUDIO as well. The set up to thread safing newlib that I've provided to some of my colleagues/customers when they've asked is basically the same as in your link. We never got around to it in TrueSTUDIO but I'll make a ticket to the MX team to hopefully have them thread safe by default upon generation of a project with FreeRTOS enabled.

[Dave Nadler]

@Markus GIRDLAND​ - Its not just thread safety (as if that isn't bad enough).

malloc fails completely in a FreeRTOS task because STM provides an incorrect sbrk function.

There are at least a dozen posts on this forum about problems this has caused (though most don't realize why they're getting crashes, memory corruption, or sprintf float failures).

You're telling us you've been aware of these problems for a year and never bothered to fix them?

Yikes.

STM really needs to get this fixed.

[JB2500]

Dave Nadler wrote:

> ST really needs to get this fixed.

Indeed they do.

They're too sluggardly for my liking.

The sbrk problem is surely a good test of their attitude and ability.

Anyway, many thanks Dave for your excellent analysis of, and solution to, the problem.

Cheers,

JB.

[Bob S]

That is a great summary and description on your web page. I can't believe that strtok() calls malloc(). I had to test that for myself, and sure enough it does. However, I can't find that malloc() call in the newlib source from sourceware.org. Not in the current 3.x version, nor in the 2.5 tag (which *may* be what I am using?????). Have you found any lib source that shows strtok() calling malloc()?

For anyone wanting to see how/where malloc() is getting linked into their code, the linker flag "--trace_symbol=malloc" will list every function that calls malloc to the console.

[Bob S]

Never mind, found it. That darned _REENT_CHECK_MISC macro expands to _REENT_CHECK which can/may call malloc() the first time strtok() is called to allocate part of the re-entry structure. strtok_r() doesn't do that.

[Dave Nadler]

@Bob S​ Thanks, make sure you like the above post ;)

Check _newlib_version.h for version info.

You can see the call sequence into malloc by breakpointing the wrapped malloc (instructions in heap_useNewlib.c).

In newlib source IIRC the malloc is in the macro _REENT_CHECK (in reent.h).

Hope that helps!

Best Regards, Dave

[crackwitz]

can I just add... THANK YOU SO MUCH for compiling that article. I ran into this problem, googled the symptoms, dug into where the hardfault happened, googled some more. it seems that most people are faintly aware of the problem and some even know to "mess with" _sbrk, but nobody else presented a proper solution or explained the intricacies.

ST really needs to open-source all of this so people can actually FIX it rather than waiting for support to get around to it.

[Dave Nadler]

I've provided an updated version of the web page and code here:

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

@Markus GIRDLAND​ - Any status update?

Please let your architecture group know they're free to contact me for any clarifications or suggestions,

Thanks,

Best Regards, Dave

[Markus GIRDLAND]

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.

[Dave Nadler]

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

What's happening???

Thanks,

Best Regards, Dave

[Markus GIRDLAND]

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.

[Dave Nadler]

@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: http://www.nadler.com/embedded/newlibAndFreeRTOS.html

Thanks,

Best Regards, Dave

[Dave Nadler]

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

Thanks

Best Regards, Dave

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

[RSylv.1]

Any news about this problem ?

[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