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

[Piranha]

More like 13-14 years since the release of STM32F1 in 2007. ;)

Actually I wonder if, except for SBSFU and probably few other rare packages, which obviously are written by other teams, is there anything in HAL/Cube code that is not broken?

[Michael B]

I think copy/paste is pretty reliable 8)

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

[RSylv.1]

Any information or confirmation ?

[Pavel A.]

@RSylv.1​ Not much information.... except of we can gather from the CubeIDE distribution itself.

The whole issue revolves around newlib-nano bundled with the ST toolchains.

Let's look at one of recent versions, v.9-2020-q2 in

[CubeIDE install dir]/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_2.0.0.202105311346/tools/arm-none-eabi

The configuration of the newlib is in ..../arm-none-eabi/include/newlib-nano\newlib.h

There you can see the following symbols defined:

#define _WANT_REENT_SMALL 1
#define _REENT_CHECK_VERIFY 1
/* Define if using retargetable functions for default lock routines.  */
#define _RETARGETABLE_LOCKING 1
/* Define if small footprint nano-formatted-IO implementation used.  */
#define _NANO_FORMATTED_IO 1

... etc. The version of newlib itself in _newlib_version.h is 3.3.0 - so you can get the source of this version and look what these macros do.

This is all ST lets us know.

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