Linker not doing what I tell it to do. I must be speaking Klingon.

[JDoe.2]

In an effort to get DMA transfers to work between the M7 core of an STM32H745 and its SPI6 interface, I want to force my buffers to go into SRAM4, which is in the same domain as SPI6. Apparently, an IDE designed specifically to program STM32's produces a barebones linker file that doesn't list anything but AXI SRAM. So I modify that file to add SRAM4 to the memory areas, like so :

SRAM4 (rw) : ORIGIN = 0x38000000, LENGTH = 64K

Since the values come from the TRM, I'm hoping they are correct. Next, I add a section which points to that new area :

.sram4 :

 {

 *(.sram4)     

 } >SRAM4

And finally, I tell everywhere where I want my buffers, for example :

__attribute__ ((section (".sram4"))) uint8_t buffer[1024];

The project compiles just fine... except it doesn't work, and when I look at the LIST file I see this :

Idx Name     Size   VMA    LMA    File off Algn

9 .sram4    00000400 20000138 0800be9c 00020138 2**2

The size is correct, but the address corresponds to DTCM.

Can somebody please explain what's going on ? What am I missing ?

SOLVED : what I was missing is I was modifying the wrong script : STM32H745ZITX_RAM.ld instead of STM32H745ZITX_FLASH.ld. A little counter-intuitive.

[waclawek.jan]

Give us the complete linker script, and then some mapfile too.

Are there any warnings when you run the linking from command line?

The GNU linker has its mostly undocumented quirks. But, after all, the most complete documentation is always available for it...

JW

PS Designed? No, it's Eclipse.

[berendi]

Can't reproduce.

I've created an empty STM32H745II project in CubeMX (1.3.1), copy-pasted the lines from your question to the appropriate places in the CM7 sub-project, added an assignment

buffer[0] = 0;

in main (otherwise it was dropped by the linker as an unreferenced object), and everything has showed up at its expected place. List file:

  7 .sram4        00000400  38000000  38000000  00030000  2**2

map file:

 .sram4         0x0000000038000000      0x400 Core/Src/main.o
                0x0000000038000000                buffer

> an IDE designed specifically to program STM32's

Whoa, kudos to ST marketing, they know something about creating impressions about their product the stuff they repackage. Next time someone would tell that ST wrote the compiler in it (which they are apparently distributing illegally).

This particular IDE was designed for programming in Java, then a C language environment was bolted on, then a cross-compiler plugin glued on top of that, then ST stuffed in a few plugins.

> a barebones linker file that doesn't list anything but AXI SRAM.

It is actually somewhat understandable, as there are lots of possible ways to share and split memory between the two cores. So they could have either asked a lot of confusing questions in the new project wizard, or do nothing about it, but leave the shareable memory areas out from both projects.

When creating a project for the single-core STM32H743, all RAM sections are at least properly listed in the MEMORY{} section.

[JDoe.2]

Problem solved : this being my first time with the STM32H7 I confused linker files. See, because I'm a simple guy, when I decided I needed to specify where variables should go in RAM, I thought I had to modify the script named STM32H745ZITX_RAM.ld but nooooo, that would have made too much sense. In fact I had to modify the one named STM32H745ZITX_FLASH.ld : now the linker does what I want it to.

@berendi : poor choice of words on my part (but then again, I'm not a native English speaker). I know full well Eclipse isn't an ST product. What I meant to say is that STM32CubeIDE is "sold" as a tool for, well, STM32 (it's in the name, for crying out loud 😁 )