Declaring variables in SRAM1-3 areas of H7 devices in STM32CubeIDE

[MikeDB]

I've searched in all the obvious places but can't find any directive to tell the compiler to place some large arrays I have in the SRAM1, SRAM2 and SRAM3 memory segments. As these are not contiguous with the AXI memory I would assume I need to place arrays there manually.

Any hints most welcome.

[Singh.Harjit]

This article shows how to put different variables in different RAMs: https://community.st.com/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices

Another article along the same lines: https://sigalrm.blogspot.com/2013/12/using-ccm-memory-on-stm32.html

[MikeDB]

Thanks. I'd seen the first one and in the first example Keil has a menu to set up the various RAM sections but I've failed to find the equivalent in STM32CubeIDE, hence I assume I'll need to do it more manually in the code.

The only definite way I've found so far is to create pointers in the AXI memory to absolute addresses in the SRAM1/2/3 sections, but that seems a little long-winded if I could just tell the compiler to locate the arrays and variables in the SRAM sections directly.

[Andreas Bolsch]

STM32CubeIDE uses gcc, so you should read the relevant gcc docs: __attribute__ ((section("my_ram")) will place the corresponding variable in elf section "my_ram". Then add the appropriate section(s) to your linker script. For an example see e. g.

STM32Cube_FW_F7_V1.15.0/Projects/STM32746G-Discovery/Demonstrations/STemWin/SW4STM32/STM32F7-DISCO/STM32F746NGHx_FLASH.ld

BTW: That's already described in the first link Singh.Harjit provided. If your're not able to accomplish that without a "menu", perhaps you should find yourself a different occupation.

[MikeDB]

I think your last comment is totally out of order as you have no idea what I am trying to achieve. The product I am designing needs to be customer-alterable and so I am trying to avoid as many complications for them as possible by using a fully integrated IDE with a complete configuration file.

Hand-modifications to the linker script could be lost at any time in the future and the customer would be stuck and need support.

[Singh.Harjit]

​I don't follow your comment about "The only definite way" and "absolute addresses".

If you assign the attribute to a variable and adjust the linker file, that variable will end up in the appropriate memory. You can still take the address and do all the normal things to the variable. In other words, applying the attribute and doing the linker change doesn't affect how you can use the variable.

For what it is worth, I've used this technique and it works just fine.

[MikeDB]

Yes I know it does but the end-user for the software isn't a computer expert (they're musicians) who need to be able to make small changes to the code and recompile easily. I always cut and paste all the necessary header stuff into a single file so that there are just two files needed - one .c and one .h - so that they have less likelihood of a compile failure. STMCubeIDE looked like a good way of simplifying things further much as Visual Studio does for PCs, Android phones and Microchip devices. But I think having a hand modified linker script is asking for trouble even if it can be stored in the project file itself as if it was lost nothing would work. Thus what I was after was some directive in the code itself that accessed these areas, but more elegant than having lots of pointers.

[Andreas Bolsch]

Well, admittedly my comment was a bit harsh. But please don't forget: You post a question because you want a solution/suggestion for your problem. Then it's your obligation to describe the problem precisely instead of more or less saying "I want a menu like in Keil". And definitely yes, I had no idea what your're trying to achieve. That's exactly my point ;)

But back to your problem: Surely there is a certain risk that a hand modified linker script gets lost or modified by chance, but the same applies for *ANY* file --- the .c file, the .h file and the project file / makefile. Moreover, it's fairly easy in most IDEs to accidentally modify one setting without realizing the overall implications. So, there is absolutely no way not to have reliable backup / versioning control, in particular as your users are supposed to modify the sources. And then, does it make any real difference whether you have three, four or seven files? If your users are able to modify the sources and flash the compiled firmware successfully, they're certainly able to keep a couple of files in a safe place as well.

Moreover the linker script has to be worked out only *once* for each device, as the available RAM sections are fixed in hardware, say with default data and bss sections in RAM1 and additionally two/four sections for RAM2 and RAM3. And, in case of initialized variables, the startup file must have the initilization code for all three sections (and enabling the RAM sections at the very beginning). Even this is fixed, no need for your customers to *ever* touch that.

All the remaining stuff will be contained in the .c file. Just add the corresponding attribute to the variables (mainly some large arrays, I guess) which should not go to the default place, i. e. RAM1.

[MikeDB]

My question was quite clear in asking how do I set the location of the variables from the compiler. Most (all?) other MCU families have C extensions to provide this facility, even if they are GCC based. I am quite able to modify a linker file but my clients are not. I was hoping they could just install STM32CubeIDE, pull in the C and H files (as they would do with Microchip devices on Visual Studio) and hit Build as all the information the generic linker requires is in the .h file.

Indeed, would the average user even on this forum know where to put the linker file in STM32CubeIDE to ensure it was used rather than the default one ? And even once they've succeeded, programming the device isn't obvious unlike with Microchip. But unfortunately Microchip has fallen behind the curve on the M7 devices so it's STM or NXP. I'm still wondering if I made the wrong choice there.

In fact ST's STM32duino toolset does do what I require very well indeed, but it only supports low end MCUs. If that was extended to the high end it would be perfect. Thus the next best thing seemed to be STMCubeIDE which I hoped would have menus that I could just provide phone support to talk people through any hassles. I understand why many experienced programmers like command line driven Linux based toolsets, but I think if they had to support customers actually making changes, rather than just emailing a new memory image, they might see the advantage of fully integrated IDEs.

And trust me musicians don't understand what backups are :) As for version control, forget it. They always say that more great music has been lost due to overwriting the tapes/discs, not turning on the recording machine, recording on the wrong track, etc, than has ever been published. Even the keyboard techs aren't renowned for making backups and they are the people who often implement the changes. The complexity of modern music generation using customisable plug-ins for Pro Tools or numerous other DAW (Digital Audio Workstation) systems would astound many of the people on here, but the lack of discipline would equally horrify them.

Anyway another issue is I have spent all day playing with the linker files to try to optimize the design first and I noticed a couple of times that memory blocks with attributes weren't being placed where asked for so even that isn't 100% reliable. Still working on why this is, but it's becoming obvious that STM32CubeIDE is still miles from being ready for the field.

[Andreas Bolsch · Accepted solution]

The setting you've to deal with seems to be quite difficult ... And you're probably right that with STM32CubeIDE or "pure" Eclipse there is little hope to solve that problem. In some way or another the IDE would have to be customized, either with an eclipse plugin or (what I'd would do as I'm not familar with eclipse internals) a makefile approach (to generate a linker script / startup file on the fly from 'comments' in the .c file). But both ways are apparently not feasible in your situation.