STM32CubeIDE + FreeRTOS + newlib = HardFault!

[RaJa]

STM32CubeIDE + FreeRTOS crashes newlib nano calls in multithread environment with sprintf("%f").

Any strtok, sprintf and other malloc calls crashes. Also USB-LL malloc calls in ISRs are not good either.

newlib reentrant doesn't help

nadler solution from http://www.nadler.com/embedded/newlibAndFreeRTOS.html doesn't work.

Github solution https://github.com/DRNadler/FreeRTOS_helpers doesn't works also, or I can't cook it properly.

newlib implementation and ST's heap manager causes HardFault.

Only StdLib for C/C++ works good, but increases code size and memory consumption greatly.

Would ST solve this problem?

[Amel NASRI]

Hi @RaJa​ ,

Did you tried to increase the Heap & Stack sizes? You can do it from STM32CubeMX perspective, at "Project Manager" tab:

 

Try this way if not yet done and please let me know if this was the solution for your problem.

-Amel

[Pavel A.]

>  Also USB-LL malloc calls in ISRs are not good either.

It's time to stop shaming ST for allocations in the USB ISRs.

Allocations from ISRs are allowed in CMSIS-OS API: see https://www.keil.com/pack/doc/CMSIS/RTOS2/html/theory_of_operation.html#CMSIS_RTOS_ISR_Calls

so Mr. Nadler slightly exaggerates the situation.

The ST USB templates do not call malloc and free! they use macros (USBH_malloc, USBD_malloc, USBD_free, USBH_free)

and user should provide implementation.

In examples without RTOS they defined these macros to malloc/free of runtime C library, whatever it is. This works for their limited examples.

If this does not work in a real application ... look for a production quality USB stack.

-- pa

[RaJa]

Yes, I did it. It doesn't help

[Piranha]

Those memory pools allocate fixed-size blocks and are not a generic heap memory. And calling malloc()/free() from ISR without __malloc_lock()/__malloc_unlock() implemented (disabling interrupts) is still broken (not interrupt safe) even without RTOS. Not to mention that is't a dumb design doing an unnecessary thing.

ST should be shamed for blatant lies - the firmware package descriptions say: "The HAL is production-ready". It took them 13 years to fix pin toggling. Even the basic UART is broken and it's API is not practically usable. It's time to stop accepting an absolute broken bloatware as a norm.

***Edited by moderation: while criticism of ST products is accepted in this community, attacks against any person - including ST employees - are not***