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

[Richard Jones]

I've just hit the Hard Fault exception when printf-ing a float, I'm not using FreeRTOS.

Heap set to 12K, stack to 1K and I'm nowhere near these from my code.

It's an STM32L433 using STM32CubeIDE 1.5.0 so bang up to date.

My project just grew 3 lines to test something (I'm getting 32-bit floats values over SPI)

uint32_t val = 0x42AA4000;

float *fp = (float*)&val;

printf("%08lx --> %f", val, *fp);

I've experimented with various settings:

--> Project --> Properties --> C/C++ Build -->Settings -->Tool Settings --> Use float with printf

---------------------------------------------------------------------------

Floating-point unit = FPv4-SP-D16

Floating-point ABI = Hardware implementation (-mfloat-abi=hard)

Hard Fault at printf

---------------------------------------------------------------------------

Floating-point unit = None

Floating-point ABI = Software implementation (-mfloat-abi=soft)

Crashes in startup_stm32L433rctx.s

/* Call static constructors */

  bl __libc_init_array <------------------------hangs when stepping from here, couldn't get any more details.

/* Call the application's entry point.*/

bl main

---------------------------------------------------------------------------

Repeat of the above 2 cases with Runtime library = Standard

Floating-point unit = FPv4-SP-D16

Floating-point ABI = Hardware implementation (-mfloat-abi=hard)

Hard Fault at printf

Floating-point unit = None

Floating-point ABI = Software implementation (-mfloat-abi=soft)

lots of compiler errors.

---------------------------------------------------------------------------

Are the fixes mentioned above going to be applicable (I've not investigated as they seem focused on FreeRTOS)?

[Dave Nadler]

The fixes I posted are FreeRTOS-specific and have nothing to do with your problem.

Do not mix hard and soft float abi - IIRC the libraries are built with hard.

Of course, that's for float only, no double hardware on M4F.

Of course, you are actually printf'ing a double (due to vararg promotion).

First, test printf with a simple double like 2.0.

Next, while 12k sounds like a lot, have a very careful look at your heap use!

Use the wrap technique I documented to check all heap allocation and make sure you're OK.

Hope that helps,

Best Regards, Dave

[Dave Nadler]

Do not rename a file to a name already used for something else!

Recipe for many sorts of disaster.

Have you got this sorted?

If so please post your mistake to help others here...

[SF??r]

Be careful with this construct: float *fp = (float*)&val;

The floating point unit should have 32 bit aligned access.

By receiving a protocol it could be broken...

For example this should cause a fault:

uint32_t my_buffer[4] = { 0 }; //align at 4 byte boarder
char *ch_buffer_p = (char*)my_buffer;
float *fp = (float*)&ch_buffer_p [1]; //break aligning
printf("%f\n", *fp);

[Richard Jones]

Thanks Dave for the speedy reply. I'll dig deeper and post any findings back. I've not actually verified heap or stack use but no RTOS and only a few kB of malloc'd data so the bulk will be whatever goes on under the covers.

Thanks SF??R, I'm receiving 16-biit words from an FPGA by SPI, concatenating them to a uint32_t (msbs << 16 || lsbs) and dropping them into 4-byte aligned malloc'd memory buffer then fprintf-ing them them to a Raspberry Pi as a csv string for use in a spreadsheet, but always good to be reminded about alignment.

[naser moravej]

Hello guys, please help me.

It didn't work for me.

I'm using stm32f429bi in a custom board I designed. CubeMX 6.1.1, CubeIDE 1.5.1, and FW_F4 V1.25.2.

I did what @Dave Nadler​ said, but it didn't work for me.

1. Exclude from all builds any current FreeRTOS heap implementation, typically something like: Middlewares\Third_Party\FreeRTOS\Source\portable\MemMang\heap_4.c. This .c file wasn't exist for me, instead I found heap_c.o in my project.
2. Exclude from all builds any current sbrk implementation. In older versions of RubeMX, ST generated a stand-alone sbrk.c module. Later versions hide it in syscalls.c. to obfuscate their messes. Get rid of it!   In the project created by cubeMX, I found this function in sysmem.c. I excluded this file.
3. Add the module heap_useNewlib_ST.c I've provided. I added this file.
4. In RubeMX FreeRTOS options, select configUSE_NEWLIB_REENTRANT + deselect "FW pack heap file". I did this also.
5. In the first compilation, I ran into undefined " configISR_STACK_SIZE_WORDS " error, I set it to 1000.

In my project I'm receiving series of array of int16_t data, then send it to MATLAB.

After doing all this works, after 18 times works (it vary time to time, some time even it works for 400 times) hang on line "configASSERT( pxQueue->uxItemSize == 0 );".

Any solution?

I attached .ioc file for more information.

TNX

[Sebastiaan]

That doesn't seem like a related problem.

Did you bump into the "hardfault" issue as described here? Do you use freertos + (memory allocation || library functions that use memory allocation (like prinf("%f"), sprintf, sscanf)?

If not, create another thread if you need help.

[DerekR]

Hello @Markus GIRDLAND​ and @Dave Nadler​ ,

My apologies for responding to a year plus old thread, but has STM fixed this in the latest versions of CubeIDE / CubeMX? If so, what versions was this fix included in? Or is Dave Nadler's patch still considered the best and most reliable solution?

Thanks!

Edit:

I contacted an STM FAE in parallel to posting this comment and was informed by them that this is still an issue and an open ticket in their system. Looks like Dave Nadler's patch is still the way to go.

[dungeonlords789]

@mattias norlander​ is this problem fix in any version?

[Dave Nadler]

@DerekR​ Honestly now, you don't want ST to rush into anything do you?

After all this has only been broken for 3-4 years.

Sadly this isn't the worst of it, just wait until you need working USB or TCP/IP...