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

[aklofas]

The STM32CubeMX platform downloaded+migrated to a new set of source files for me last night for the STM32F407 chip I'm using. I don't want to get too ahead of myself, but the hard-faulting errors that @Dave Nadler​ fixes with his heap4.c patch don't seem to be present with the "stock" source code anymore.

Could it be true? Can someone please independently verify STM has fixed this issue?

[crackwitz]

I only see cubeMX 5.6.1 and cubeF4 that is a few months old

[Dave Nadler]

Last I looked the ST implementation still had a bunch of bugs, beware...

[robert239955_stm1_stmicro]

Did anyone try with nanolib 3.3.0?

[Dave Nadler]

Due to popular demand, I’ve updated and placed a couple of components on Github: https://github.com/DRNadler/FreeRTOS_helpers, including:

• heap_useNewlib (stop those nasty memory-management crashes), and
• a port.c for Cortex M4-7 that adds MSP (ISR) stack checking

I’ve also updated and expanded the web page http://www.nadler.com/embedded/newlibAndFreeRTOS.html.

Hope you find this helpful!

Best Regards, Dave

[kj.obara]

Hi Dave, everyone,

I've run into this exact problem and I was trying to use Dave's replacement for port.c and heap_4.c (I renamed files from Dave's GitHub to the names from freeRTOS).

I've added #define MALLOCS_INSIDE_ISRs to heap_4.c and

#define configUSE_NEWLIB_REENTRANT 1

#define configISR_STACK_SIZE_WORDS (0x100) // in WORDS, must be valid constant for GCC assembler

#define configSUPPORT_ISR_STACK_CHECK 1 // DRN initialize and check ISR stack

extern unsigned long /*UBaseType_t*/ xUnusedISRstackWords( void ); // check unused amount at runtime

to FreeRTOSConfig.h

But I haven't made any changes to the linker script.

I thought that would be sufficient to have this working but a sprint function with three float numbers inadvertently ends at the breakpoint Dave setup.

I suppose I must have misunderstood something from the instructions.

Could anyone offer any suggestions? Many thanks.

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

[RSylv.1]

Someone posted an issue in the ST Github ? https://github.com/orgs/STMicroelectronics/projects

[NMerc.1]

Hi, I've been struggling with this issue for a week or two now. I'm new to STM32 so I'm confused.

I converted an old project to the a CubeIDE project and ran into this problem. But new projects generated by the cube seem to be fixed.

No more faults on new / malloc in rtos threads. (We are using FreeRTOS. )

I see the fix in sysmem.c ( void *_sbrk(ptrdiff_t incr) ) and theirs no more problems with new and malloc.

But is this fix enough or should I be looking deeper.

Is it fully solved by ST or is their something else I'm missing.

I did set USE_NEWLIB_REENTRANT 1

I'm not even sure if I'm using newlib or not, it should be simple to figure out but for some reason it is not clear to me and the documentation and configuration is confusing.

Is their a simple way to know if I'm using newlib ?

thanks

Nathaniel

[SF??r]

Is this major problem fixed? Any updates?

[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

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