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

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

[RSylv.1]

Any information or confirmation ?

[DerekR]

Hello again,

Looks like STM has released a fix for this in the latest STM32Cube IDE 1.7.0 / CubeMX 6.3.0 release according to their release notes:

I haven't tested this or investigated the fix, but figured I would update this thread to raise awareness. Note that if my memory serves me correctly, STM released a fix in the past that didn't work. So before anyone deems this a working fix, I would investigate yourself or wait for peer verification. @Dave Nadler​  in case you are curious.

Derek

[dungeonlords789]

STM32CubeIDE errata

https://wiki.st.com/stm32mcu/wiki/Category:STM32CubeIDE_errata

[RSylv.1]

Any information or confirmation ?

[Dan in WY]

I tried increasing the stack in my freertos task but that didn't help. So I just multiply the fp by 10^n (n is the precision or where to put the decimal point) cast it to a int32_t and use this routine to insert a decimal point:

void insert_dp(int32_t num, char *buff, int nodp)
{
	char temp[10];
	int i,j;
 
	memset(temp,0,sizeof(temp));
	sprintf(temp,"%ld",num);
	int strln = strlen(temp);
	j = 0;
	
	for(i = 0;i <= strln;i++)
	{
		if(i == nodp)
		{
			buff[strln-i+1] = '.';
			j++;
		}
		buff[strln-i-j+1] = temp[strln-i];
	}
}

[PHolt.1]

The problem with %f printf issues is that newlib printf uses the heap for floats (and longs). See

https://community.st.com/s/question/0D53W00002FDxFDSA1/does-cube-mx-build-the-libca-printfcanfheapetc-library

[Dave Nadler]

@PHolt.1​  Why are you posting something already explained in detail above and in my web site you reference?

And incorrect information in the linked article?

Please stop wasting everyone's time.

[GMock.1]

You may want to check out this discussion with Dave. From studying the generated code and the docs, I think the "FreeRTOS strategy #5: deny lock usage from interrupts" might in fact work, and I am experimenting with it, but it is too early for any final conclusion, and I cannot say anything about the other "strategies".

[Dave Nadler]

@GMock.1​ - "Might Work" ? Hope is not a strategy...

Sorry I'm too busy at the moment to check out ST's latest attempts.

But given its the same staff that have delivered innumerable failed attempts in past, poor probability of solid results...

[GMock.1]

@Dave Nadler​ As I said, I am evaluating their solution instead of just "hoping" it will work: I have read the documentation, I have studied the generated source code and (to some extent, more to do) followed execution paths on an actual device in the debugger. So far (and for strategy #5 only), I have not seen anything that is not working by design at all (like previous releases) or has bugs in its implementation. I also did not encounter any mysterious crashes (but that does not mean much, as I still need to run long time stabiltiy tests with random mallocs etc). That is what "it might in fact work" means.

It is always easier to prove something wrong than to prove it right. In any case, more people need to have a look at it, otherwise we will never know for sure.

[PHolt.1]

I don't understand what is going on here.

As I wrote above, the newlib printf and heap lib which comes with ST Cube IDE (and thus gets generated by Cube MX) is stuff from 1990 and it has been built badly, with mutex protection in the right place but with the mutex calls being empty stubs. This can be fixed but not completely trivially because libc.a (where all this stuff lives) was compiled without the symbols being "weak".

That link to Dave Nadler's site is a zipfile containing the following

which I cannot understand the relevance of. Most/all of those files have no relevance to this problem.

[Piranha]

Of course ST couldn't do it without breaking and messing up something...

https://community.st.com/t5/stm32cubemx-mcu/cubemx-generated-threadsafe-stm32-lock-h-potential-bug/td-p/77220