Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


malloc heap issue with CubeMX Project

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 frown
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 question

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

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)


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