Arduino for STM32

i've occasionally seen my sketches/firmware crash and i think it is caused by the stack overwriting heap memory. there is only 20k sram on bluepill (stm32f103) style mcus after all. i'd guess sometimes with various functionalities integrated together, it is quite possible to run out of memory.
there doesn't seem to be an 'easy' way to detect this, i'm not sure if the memory protection features on the mcu could be used to detect this condition.

is there a way to use the memory protection features (say on stm32f103) to detect this?

edit:
i did a little google search and stumbled into these
https://www.st.com/resource/en/applicat ... ronics.pdf
https://www.iotality.com/armcm-access-levels/

it seemed an implementation can require rather significant stack redesign as it may imply that writing to the heap always requires a 'privileged' mode.
And that 'privileged' mode can only be accessed from an exception or service call

Hi ag123, even if you could protect the heap, this would not solve the real problem.
The real problem in these cases is not just that the stack invades the heap memory but rather that the application makes the stack growing too much respect to the available memory and this is due to the application design.
So to me the real solution is to design an application and use APIs that "by design" limit the maximum stack size.
Else you could always end up in application errors due to stack overflow errors.

This article is interesting and directly pertinent to PlatformIO:
https://medium.com/coinmonks/stm32-blue ... c805e16ed7

STM32duino build would require editing the boards.txt to include the linker map file output name. Otherwise, I suspect the results are the same or similar enough.

Ray
Added:
This old Leaflabs forum post is interesting http://forums.leaflabs.com/forums.leafl ... ml?id=2369 and discusses Libmaple. The include file is syscalls.c and is included in Roger's core repository under the variant folders:
https://github.com/rogerclarkmelbourne/ ... syscalls.c

In syscall.c this is mainly the _sbrk() function (used by all alloc ot the lib c) which have to be properly defined using some linker script "definition":
https://github.com/stm32duino/Arduino_C ... .c#L29-L51

One thing I probably do not manage is the reentrance...

hi thanks all,
for now it'd seem adding such features could take a re-design than simply an add on. i.e. gcc allocate global vars and buffers say statically
i'd probably re-look again some other time
and thanks for the _sbrk() reference, that is actually useful as on top of the pre-allocated static and global variables, is that malloc() based dynamic heap.
from ray's links, that free memory function is interesting.
there is an implementation from
greiman / SdFat
https://github.com/greiman/SdFat/blob/m ... reeStack.h
https://github.com/greiman/SdFat/blob/m ... eStack.cpp
that implementation actually works in stm32, i actually tried it in some context, e.g. to check that it doesn't trash the heap at the deepest nesting.
however, as it turns out that may even be difficult as large file systems e.g. sd cards may have large directory structures, fats etc, it easily consume stack space to some extent it may trash the heap at times especially on the 20k sram blue pill.
nevertheless, it is a very useful function to figure out the 'dynamic range' of memory use.

accordingly it is possible to allocate memory on the stack rather than heap, using alloca()
https://stackoverflow.com/questions/633 ... y-on-stack
i think if the function is after all implemented, it is useful in the 'arduino' context as the stack gets unwound after the call and memory is freed.
but doing that risk 'smashing the heap' where the global vars and static arrays are stored.
i'd think it is somewhat better than malloc() as malloc() tend to end with fragmented heap as allocated blocks are not free()ed in the same sequence.

Forgot to mention this example which can be useful:
https://github.com/stm32duino/STM32Exam ... istics.ino