stm32h7 dtcm ram overflowed

[VYoun]

Hello,

I am relatively new in this field, and need assistance for my project at work.

Recently, in order to have more RAM, I switched from STM32F4 to STM32H7.

I saw that STM32H7 has 1MB of RAM, and decided to base our system on this MCU.

However, after compiling my code, I see that only DTCM RAM is used by the MCU and others are not used.

The DTCM RAM is now full and I can not move any further with my code.

How can I make use of RAM_D1 or RAM_D2 for my variables?

I am using CubeMX and Atollic Truestudio.

Please kindly help me as this is vital for my work. Any help is greatly appreciated.

[alister]

My earlier posts had been inaccurate and I've edited them again.

Don't not use DTCM-RAM at all. It's your fastest memory.

If your app initializes .data and zeros .bss correctly in AXI-SRAM and crashes later, it suggests some other problem may be the cause.

You need to isolate the cause.

Hard fault? Some good information's at https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html and in many posts to Community.

Otherwise, load the app in the debugger and step until it crashes. Remember where, debug again. Iterate, each time getting closer. If the problem's complex, instrument the code to catch states, events or anything helpful. If the problem's simple, sometimes just stopping the debugger while the app's crashed is enough.

[VYoun]

I was reading my linker file more carefully, and realised that mine has no AXI_SRAM_D1.

Instead I have SRAM_D1 which is 512k, could this be the reason why my code stops working when I bring .bss, stack, and data to SRAM_D1?

Thank you in advance for your help.

Best regards,

Vouria

[alister]

Atollic TrueSTUDIO uses GNU toolchain. GNU linker is described at https://sourceware.org/binutils/docs/ld/index.html. GCC compiler is described at https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html. These links are their head doc versions. TrueSTUDIO 9.3.0 uses "GCC 6.3.1 20170215 + patches" and "Binutils 2.27.90.20170215". If you hunt around a bit you'll find earlier version docs closer to your tools. But these'll serve for most matters.

>mine has no AXI_SRAM_D1.

The question is quickly answered in the section in the linker doc about the MEMORY command.

>my code stops working when I bring .bss, stack, and data to SRAM_D1

It'd be much easier to help if you provided more details. In no particular order...

1. Where does it stop working?
2. How does it stop working?
3. What version of TrueSTUDIO are you using?
4. Did you create the project with Cube?
5. What version of Cube?
6. Other observations?
7. Guesses?

A general practice for debugging...

1. Execute until it fails. Glean details from the machine state (registers, variables, memory, etc), to learn e.g. where has it executed to, what is the nature of the fail. For hard faults I Googled and found https://www.youtube.com/watch?v=E52v1p6CN5A about TrueSTUDIO's Fault Analyzer. I haven't viewed this one. If it's no good, Google another.
2. Set a breakpoint somewhere earlier and step closer to the fail location and confirm, e.g. by inspecting yours and GCC's and ST's code, the prerequisites are met, and events are consistent with states, etc.
3. If the fail is more complex, instrument the code, e.g. add static-storage-class variables (globals) to store details that you can check after the fail, or add printfs if you've implemented ARM ITM or other mechanism for standard output (and there's not much output, as if you overrun this it'll probably be ineffecive), to understand the path of execution.
4. If the fail is more complex, find some unused pins, turn them into outputs and wire them to a CRO to show the path of execution, critical timings, decisions, etc.

[VYoun]

Hello,

Thank a lot for this complete answer. I will go through the links regarding the GNU linker and the GCC compiler. These are very good to learn, in order to improve my knowledge. I am using TrueSTUDIO 9.3.0.

Thanks very much for the suggestions regarding debugging, and fault finding in the code. These are very useful for me, cause I am really new in this field, and normally under much pressure from my work cause I do not yet know my way around things.

Yesterday, I used the memory map and the suggestions here to make changes in the linker file. I brought .bss to the RAM_D1 and left the rest as it is. Now the program is working fine.

I think the problem was that I brought heap and stack into the RAM_D1. Now I left heap and stack to be in DTCMRAM.

Thank a lot for your help.

Best regards,

Vouria