Showing results for 
Search instead for 
Did you mean: 

Moving some data to another RAM region

Associate III


I'm having trouble using different regions of MCU's internal RAM. STM32H7 has 4 different RAM regions and I can't use them properly. So far I'm only able to move individual variables or functions into different than default regions by putting __attribute__ ... directly in the code.

In .bss section there's entity "FrontendHeap::getInstance()::instance" which occupies almost whole RAM region. 
Questions are:
How to move that instance to different RAM region? Is that even possible or is it conceptually wrong?
Can I move all TouchGFX related data to another RAM region?
Maybe I could move individual .o objects into different regions?
Any example or appnote for this?


In demo project "stm32f7_performances" linker file being heavily manipulated - but I'm more confused by this example than found answers.
Potentially I'd like whole TouchGFX code and run-time data to be executed from external DRAM, but this maybe for another conversation.




Some memories need to be explicitly enabled.

In terms of initializing content, the GNU/GCC compiler / linker expect you to manage the allocation, and staging on content so that the code in startup.s can either zero, or copy content out of staging areas in FLASH. You have to determine the beginning/end of each section with symbols, and also the place in FLASH it gets placed.

IAR and KEIL deal with this better, the linker creates tables per the scatter file, and the scatter loader processes that automatically. Arduino's GNU implementation is also better, and similarly table driven.

Code you have in SystemInit() is also expected to bring up clocks, memory interfaces, and pins so the run time initialization code in startup.s can fully do it's job, and the memory is viable when the C++ constructors are called.

SDRAM is typically the slowest, longest latency memory available. Generally not good for code or stacks, but the caching can hide some of the ugliness. Internal FLASH is also rather slow, but has very wide fetch lines, and prefetch / branch-prediction can hide that, via ST's ART

Watch most of the _sbrk implementation's ST has been using assume the stack/heap reside in the same memory, and the SP is used as a ceiling for the heap. Better implementation might use symbols from the linker.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thanks for the reply.


I moved FreeRTOS's heap to another region instead. That solved problem for now and was more straightforward (just in case ). 

Yet I still don't know linker settings to move whole .o files.