Loading...
 
Skip to main content

System Workbench for STM32

Forum List Topic List

Forums » System Workbench for STM32 » malloc heap issue with CubeMX Project
 
Thread actions
Print this page
  • Print all pages

    • malloc heap issue with CubeMX Project

    Posted by diabolo38 on 2015-04-11 23:16

    I use an F401 project generated by CubeMX i started with only FatFS + few perif
    atFS use some large malloc (1024+ few byte) bt it works f_open and read from sd is ok

    I then added freertos that used quite a lot of memory fr it's own heap
    but then FatFS fail cos malloc to anything bigger than 512 bytes fail 🙁
    By changing the ld file _Min_Heap_Size i can work it arround
    but i'm not much satisfied as from the map is see that ther's about 64KB( 0x2001FFFF - 0x20008d64) of ram unsued for the heap so it should not fail ❓

    I'm not sure to understand all the symbol defintion and what is what
    but it's weired stack shall be at top of ram ie = _estack
    so heap max set to estack - min_stack_size
    i kind of feel it's not quite the LD and map below say
    it's like if stack is placed just after the minimal heap ?

    ld
    /* User_heap_stack section, used to check that there is enough RAM left */
    ._user_heap_stack :
    {
    . = ALIGN(4);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    . = . + _Min_Stack_Size;
    . = ALIGN(4);
    } >RAM

    map

    ._user_heap_stack
    0x20006d64 0x2100 load address 0x08013140
    0x20006d64 . = ALIGN (0x4)
    0x20006d64 PROVIDE (end, .)
    0x20006d64 PROVIDE (_end, .)
    0x20008d64 . = (. + _Min_Heap_Size)
    *fill* 0x20006d64 0x2000
    0x20008e64 . = (. + _Min_Stack_Size)
    *fill* 0x20008d64 0x100
    0x20008e64 . = ALIGN (0x4)




    I have over non ac6 project wiht FreeRTos+gcc and have no such issue but the stack
    and heap are defined different way

    0x20020000 __stack = (ORIGIN (RAM) + 0x20000)
    0x20020000 _estack = __stack
    0x00000400 __Main_Stack_Size = 0x400
    0x00000400 PROVIDE (_Main_Stack_Size, __Main_Stack_Size)
    0x2001fc00 Main_Stack_Limit = (stack - __Main_Stack_Size)
    0x2001fc00 PROVIDE (_Main_Stack_Limit, __Main_Stack_Limit)
    0x00000100 _Minimum_Stack_Size = 0x100
    0x2000753c PROVIDE (_Heap_Begin, _end_noinit)
    0x2001fc00 PROVIDE (_Heap_Limit, (stack - Main_Stack_Size))

    Can you help ? Is this an issue of ST CubeMX LD files ?
    thanks

    STM32F401RETx_FLASH.ld (4.42 Kb)
    Reads: 24785
    Posted by diabolo38 on 2015-04-13 14:12

    after searching more the issue is in sycall.c _sbreak function provided by both CubeMX and ac6 project.
    the heap increase check is not adpated to an rtos env (stack is in user ram area sp is not any more the main stack)
    The heap break check condition is not perfect
    ld file and sbreak should be fixed to compare first it is less than min heap and only if not checking vs stack
    so it suceed even in rtos env until min heap is not consumed

    ie
    caddr_t _sbrk(int incr) {
    extern char end asm("end");
    extern char _min_heap_end asm("_min_heap_end");
    static char *heap_end;
    char *prev_heap_end;

    if (heap_end == 0)
    heap_end = &end;

    prev_heap_end = heap_end;
    if (prev_heap_end + incr > &_min_heap_end) {
    if (heap_end + incr > stack_ptr) {
    // write(1, "Heap and stack collision\n", 25);
    // abort();
    errno = ENOMEM;
    return (caddr_t) -1;
    }
    }
    heap_end += incr;
    return (caddr_t) prev_heap_end;
    }

    LD file changed to
    ._user_heap_stack :
    {
    . = ALIGN(4);
    PROVIDE ( end = . );
    PROVIDE ( _end = . );
    . = . + _Min_Heap_Size;
    PROVIDE ( _min_heap_end = . );
    . = . + _Min_Stack_Size;
    . = ALIGN(4);
    } >RAM



    A work arround it s to do a first malloc and free in main prior to start scheduler to setup the user minilal heap
    for the time being it's what i'll use as ld file options are overwriten by CubeMX on code generation (a user section would be nice)


         Posted by johannes.visser@msc-technologies.eu on 2019-12-05 16:04

    I recently encountered the same problem and fixed it with the modification on _sbrk in syscall.c shown above.
    This topic is quite old. But CubeMX still generates this faulty syscall.c when RTOS is used.

    By the way, this effect is also responsible for printf float creating a hard fault when using with -u _printf_float and RTOS.

    Im am using CubeMX 5.4.0 on a STM32L4R7Z