Electronics > Microcontrollers

STM 32F4 stack overflow protection

(1/5) > >>

peter-h:
The project runs FreeRTOS, with the #4 memory model, where a fixed buffer is declared and the RTOS allocates process stacks out of that.

That buffer is 48k and goes into the CCM.

The stack is 16k and takes up the rest of the CCM, obviously working down from its far end. This is used in main.c (very little there), for ISRs, and some other stuff, none of it big.

I realise that in an embedded system there is little you can do if things run away :) but is there any way to set up a trap for SP going below some address?

Probably more useful would be to zero the whole CCM and have a task running every say 10 secs which looks for nonzero values and prints out some sort of graphic representing these... and run the target for a few days. With a VT100 terminal one could do a nice graphic :)

MadScientist:
Depending on the exact M4 core you could use the memory protection unit to provide a no access zone between the two memory zones , the region size on M4 can be quite small so only a small amount of ram is wasted.

peter-h:
It is a 417. I will dig around - thanks.

This is probably asking way too much but is there any way to use the Cube IDE debugging tools to generate such a graphic? It seems to have 100x more features than anybody could ever use :) Probably that would need the use of temp breakpoints, like any other form of execution profiling, which is another thing that would be interesting.

Alti:
If this memory is allocated by OS then this is portion of memory is called heap. It is the code execution flow that decides the allocation, size, sequence, freeing etc. Of course you could play with MPU and run-time configure it but that is going to be quite an assignment.
Reconsider your decision about dynamic (run-time) memory allocation, most uC embedded applications do not require heap. Then memory partition is made statically at linking stage (use linker for that). Also, when all stacks have fixed addresses, MPU configuration becomes super simple.

As for using DWT for tracing memory problems - sure, you could do that but there is quite a limited count of those data traps (I think only 2 in CM3/4).

I do not know Cube.

cv007:
Put the stack at the bottom of ccm, when it goes below a usable address- bus/some fault.

Navigation

[0] Message Index

[#] Next page