Load code in RAM directly from STM32CubeIDE through STLink

[Gpeti]

I want to load a piece of software directly to the STM32H7 internal RAM. I precise that I don't want to load some code in Flash and copy it into Flash at runtime, I want to load directly to the part's RAM.

I've linked my executable to map the function in RAM. I checked it is correctly mapped by readelf and I also converted the .elf to .hex to check manually that there is indeed some code located @ 0x24000000.

When I load the .elf through STM32CubeProgrammer I can see that the RAm is correctly loaded.

But when I load through STM32CubeIDE (by launching a debug session, using ST GDB server) the RAM is not loaded.

Is there a setup I am missing ? Or is it a known limitation of the IDE or ST GDB server ?

[Tesla DeLorean]

Other tools require loading via debugger script, or command line of the debugger. Check docs.

[Gpeti]

I'm sorry, I didn't understand what you mean. Do you mean that I have to load my software from the IDE but with a debugger script ?

[Gpeti]

By default there is no script in STM32CubeIDE debug configuration. I don't see why there should be a script for loading anyway since the elf gives all information about memory mappings.

[Tesla DeLorean]

Most debuggers, that I use, presume the code/data is already in memory via tools/algorithms that update FLASH, for RAM, you frequently have to explicitly LOAD the object or hex files, via the debugger's command line invocation, a script the debugger runs, or you type in explicitly a the debugger's command input.

@Markus GIRDLAND​ 

>>I don't see why there should be a script for loading anyway ...

But you're here because it doesn't work. Most times the .ELF/.AXF is passed as a HOST side reference for the debugger, it is usually not tasked with delivering it to the TARGET, so there's probably a switch or script needed.

[Gpeti]

I just found out that the loading in RAM is working fine with "OpenOCD" debug configuration... So it simply looks like "STLink GDB server" has a bug/limitation.

I noticed that STLink GDB server seems to use STM32CubeProgrammer to load the binary, according to the console output:

Waiting for debugger connection...

Debugger connected

     -------------------------------------------------------------------

                      STM32CubeProgrammer v2.1.0                 

     -------------------------------------------------------------------

Log output file:  C:\Users\GPETIT~1\AppData\Local\Temp\STM32CubeProgrammer_a06056.log

ST-Link Server is running on port : 7184

ST-LINK SN : 003A00393137511033333639

ST-LINK FW : V3J3M2

Voltage    : 3.30V

SWD freq   : 24000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID  : 0x450

Device name : STM32H7xx

Flash size : 2 MBytes

Device type : MCU

Device CPU : Cortex-M7

Memory Programming ...

Opening and parsing file: ST-LINK_GDB_server_a06056.srec

 File         : ST-LINK_GDB_server_a06056.srec

 Size         : 29088 Bytes

 Address      : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sector 0

Download in Progress:

File download complete

Time elapsed during download operation: 00:00:01.248

For OpenOCD there is no detail on the specific tool used to load.

[Markus GIRDLAND]

ST-LINK GDB server invokes CubeProgrammer for the flash handling, yes.

If you want to analyze it more in-depth you can activate the GDB Server log in the debugger tag of the debug configuration.

How does the linker script look? If the project is generated through CubeMX (either stand-alone or the integrated one) it usually comes with two linker script where one is for running the application in RAM.

[Gpeti]

It is not a matter of linker script since, as I said, the loading in RAM works fine with openOCD and also with STM32CubeProgrammer (I mean the CubeProgrammer windows application).

it fails only with STLink GDB server. I guess there is a mistake in the setup of the call to STM32CubeProgrammer by STLink GDB server.

[Pavel A.]

In Atollic loading to RAM on STM32H7 works well, so could be a regression in CubeIDE.

But OP, please check the *debugger config* script too, the IDE generates it automatically and differently for flash or RAM.

It takes this hint somewhere in the project settings.

-- pa