2022-11-29 11:53 PM
I am using an STM32H7 (though this would apply to any other STM32 with different RAM sections) and want to put the Stack in the fast DTCMRAM section, while freeing up the D1RAM for the Heap.
This did in fact work with the old toolchain of GPDSC, but not with the current CUBE-IDE Toolchain.
The symptoms are: in __libc_init_array the program hits an exception and hangs up while trying to get the new handler.
The base of the problem seems to be: In the sysmem.c -> function _sbrk the max_heap and the stack_limit are associated. This is kind of useful when both are in the same section, but does not let the program use separate sections.
Since that file is cube-mx generated, a custom implementation of the sbreak routine does not look like a good practice, since it would get overwritten on each generation.
Is there another way to achieve this separation of heap and stack?
Best Regards,
Jan
Solved! Go to Solution.
2022-11-30 07:53 AM
> a custom implementation of the sbreak routine does not look like a good practice, since it would get overwritten on each generation.
No, this should not be this way. IIRC the sysmem.c (or syscalls.c or whatever file that implements sbrk) is created only once from a template, and generator does not touch it afterward. It is considered a user file. You are free to change it as you like.
2022-11-30 07:19 AM
You need your own custom _sbrk() function that knows the size/location or your heap area. As you've found, the stock version presumes heap and stack are contiguous and heap consists of all RAM after _end up through the end of RAM minus the min stack size (at least in the one project I checked).
2022-11-30 07:35 AM
I agree that a custom sbrk would be possible, but since it would get overwritten on the next generation of cube-mx files it is not a solution I would prefer.
I hope in one of the following cube-mx releases there would be a possibility to switch that check off.
2022-11-30 07:53 AM
> a custom implementation of the sbreak routine does not look like a good practice, since it would get overwritten on each generation.
No, this should not be this way. IIRC the sysmem.c (or syscalls.c or whatever file that implements sbrk) is created only once from a template, and generator does not touch it afterward. It is considered a user file. You are free to change it as you like.
2022-11-30 11:01 PM
Ok, still not ideal for porting accross projects, but seems to be the only way.
2022-12-01 01:51 PM
Put your custom/modified _sbrk(), etc. is a separate file, then flag the CubeMX generated sysmem.c as "do not compile" in the IDE.