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.

[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]

>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.

[Ceco]

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

I will give an example:

I want to place my heap memory, BSS and all "non-special" variables in SRAM1 region which will work with DCACHE enabled for better performance.

In the same time I have some buffers which will be used with DMA access. So it will be better to place them in DTCM-RAM, correct?

To deal with this separation, normally I'm using __attribute_section when variables are defined in the code. But to do it, I need clear separation of these sections in linker file also.

Normally I can edit linker script manually, this is clear. But I had some expectations from my previous experience with other cores as F4 and H7 which has this section separation already done by STM32CubeMX in the generated linker file. For me it's strange especially for F7 MCU to not have it, because due to the DCACHE and DMA usage conflict normally you need this separation in almost all usage cases. 

Anyway - I will do it by myself. Thanks for the answers.

[TDK · Accepted solution]

That makes sense, thanks for the explanation

F7 is somewhat unique in that DTCM is a sizeable portion of the overall memory. They could have chosen to define RAM such that it's the largest, which is a fine choice for something generic. No one size fits all solution here.

[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.