Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32

Forum List Topic List

[ prev topic ]  

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

STM32F401RETx_FLASH.ld (4.42 Kb)
Reads: 20609
Link
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)

Link

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

Link