Skip to main content
RaJa
RaJa
Associate II
February 2, 2021
Question

STM32CubeIDE + FreeRTOS + newlib = HardFault!

  • February 2, 2021
  • 4 replies
  • 1780 views

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?

This topic has been closed for replies.

4 replies

Amel NASRI
Amel NASRI
ST Technical Moderator
February 9, 2021

Hi @RaJa​ ,

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

0693W000007EZCrQAO.png 

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

-Amel

To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
RaJa
RaJaAuthor
Associate II
February 10, 2021

Yes, I did it. It doesn't help

Pavel A.
Pavel A.
February 9, 2021

>  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

Piranha
Piranha
Principal III
February 10, 2021

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***

Terms & ConditionsAccessibility statement