2019-08-06 01:20 PM
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
Solved! Go to Solution.
2020-05-19 11:26 AM
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?
2020-05-19 12:34 PM
I only see cubeMX 5.6.1 and cubeF4 that is a few months old
2020-05-19 03:43 PM
Last I looked the ST implementation still had a bunch of bugs, beware...
2020-05-19 05:47 PM
> look into _REENT_SMALL
This involves rebuilding the newlib (nano), correct? Are there directions how to build it for CubeIDE or Atollic toolchain?
-- pa
2020-06-17 12:19 PM
Did anyone try with nanolib 3.3.0?
2020-07-12 05:46 PM
Due to popular demand, I’ve updated and placed a couple of components on Github: https://github.com/DRNadler/FreeRTOS_helpers, including:
I’ve also updated and expanded the web page http://www.nadler.com/embedded/newlibAndFreeRTOS.html.
Hope you find this helpful!
Best Regards, Dave
2020-07-28 03:43 PM
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.
2020-08-07 02:16 AM
Someone posted an issue in the ST Github ? https://github.com/orgs/STMicroelectronics/projects
2020-09-27 06:17 PM
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
2020-10-27 01:03 AM
Is this major problem fixed? Any updates?