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

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.

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.

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.

Actually a makefile approach sounds possible - I'll give it some thought. For now I've just declared all the small variables as members of a struct and allocated that to one of the SRAMs, but moving the stack to DTCM memory (where surely it should belong by default ?) without modifying the linker file seems to be impossible.

I originally looked at actually compiling and linking on the H750s themselves - they are each more powerful than early 1990s PCs we happily did this on all the time - but can't seem to find a suitable base to start with.