Linker script with detailed sections

[Ceco]

Hello. I'm using STM32CubeMX with STM32f777ZI MCU to create a CMAKE project.

The generated linker script file (STM32F777XX_FLASH.ld) has a really simple definition of RAM memory regions:

/* Specify the memory areas */
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 512K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 2048K
}

There is no separation of SRAM1, SRAM2, DTCM and etc. For example - I want to enable cache in SRAM1 and I need to have a proper section definitons. I want to use in my code something like:

__attribute__((aligned(sizeof(uint32_t)), section ... and etc.

Is it possible to force STM32CubeMX to generate more detailed RAM segmentation for F7 cores?

[AScha.3]

Hi,

so just make a project for STM IDE, it should look like mine (for H743): + depends, what your cpu has...

/* Specify the memory areas */
MEMORY
{
 FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 2048K
 DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
 RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K
 RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
 RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
 ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
}

Then copy and write, what you want.

btw

Enable D-cache for some area or not is by setting the MPU , not the linker script.

 

[Ceco]

>Enable D-cache for some area or not is by setting the MPU , not the linker script.

Yes I know. But how to place a variable in exact RAM region (SRAM1 for example) if I don't have a properly defined sections in the linker script?

>No, the linker scripts are provided as-is. You'll have to modify it yourself to suit your needs.

A clear answer, thanks. But why the section definitions for other MCUs are better defined (for example F4, H7)...

For F7 the generated linker script is not usable at all if you plan to use D - CACHE and DMA.

 

[TDK]

> A clear answer, thanks. But why the section definitions for other MCUs are better defined (for example F4, H7)...

In general: There are thousands of chips. You're going to find some inconsistencies and differences.

But in particular, what's missing from the linker script you posted? The RAM region contains DTCM, SRAM1 and SRAM2. Or you just want it better separated into sections?

On the F4, CCMRAM is not contiguous with SRAM so it can't be part of the RAM section. 

 

> For F7 the generated linker script is not usable at all if you plan to use D - CACHE and DMA.

Not sure I understand this. DCACHE isn't a part of the linker script and can be enabled in CubeMX. Same with DMA.

[TDK]

> Is it possible to force STM32CubeMX to generate more detailed RAM segmentation for F7 cores?

No, the linker scripts are provided as-is. You'll have to modify it yourself to suit your needs.

[STackPointer64]

Hello @Ceco, and welcome to ST community!

Unfortunately, this is not possible unless done manually by following this format:

REGION_NAME (xrw) : ORIGIN = 0xSTARTING_ADDRESS, LENGTH = SIZE

After that, you can create sections and assign variables to them in your application.

Best regards,

[Ceco]

Yes, this could be a problem. I looked at the ready-made examples in STM32Cube for STM32F769 Discovery kit - the linker file for STM32CubeIDE is the same with one large RAM section. DCACHE is turned on at the start up. This will work as soon as the user does not exceed the 128Kbyte RAM limit. After that, the first DMA transfer will stop the game.

For me, the linker script is the skeleton of the project. All the code relies on it. And it is extremely important in the case of STMF7 devices to manage the cached areas. So at least there should be a comment that the linker script should adapt according to the cache and DMA usage.