How to write the scatter file for Keil uVision to force linker to allocate variables in SRAM?

Question

Development environment

I'm working with STM32F427 and I use Keil uVision V5.29 to develop my application. The version of the ArmCLang Compiler, of the Assembler and the linker is 6.131.1.

Scatter file and __attribute__ directive

I need to allocate some variables in the SRAM into the address interval:
[0x20000000, 0x20030000]
The variables are at least the following:

ETH_DMADescTypeDef  DMARxDscrTab[ETH_RX_DESC_CNT];
ETH_DMADescTypeDef  DMATxDscrTab[ETH_TX_DESC_CNT];

I have tried with the __attribute__ directive as following:

ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] __attribute__((section(".ram1")));
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] __attribute__((section(".ram1")));

I have defined the following scatter file:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x08000000 0x00200000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00200000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  RW_IRAM1 0x20000000 0x00030000  {  ; RW data
   *(.ram1)
  }
  RW_IRAM2 0x10000000 0x00010000  {  ; CCM
   .ANY (+RW +ZI)
  }
}

Compilation error

If I compile the project with the previous scatter file (with or without the __attribute__ directive) the compilation output shoes many of the following error:

...: Error: L6406E: No space in execution regions with .ANY selector matching app_azure_rtos.o(.bss.variable_name).

My question

Where is it the error in the previous scatter file?

---

EDIT
I have found this link which suggests that there is not enough resource for the program.

But if I use the following scatter file (where it is completely excluded the CCM memory and this means that 56 Kbytes of RAM are not used):

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x08000000 0x00200000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00200000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  RW_IRAM1 0x20000000 0x00030000  {  ; RW data
   .ANY (+RW +ZI)
  }
}

the compilation ends successfully. This means that the problem is in the scatter file not in the memory resources.

Answer 1

After a bit of research I have found the necessary and missed option for my scatter file.
To compile the project it is sufficient adding the following option to the RW_IRAM1 region:

.ANY (+RW +ZI)

where RW means Read/Write and ZI means Zero Initialized.

Correct scatter file

So the correct scatter file for my needs is:

; *************************************************************
; *** Scatter-Loading Description File generated by uVision ***
; *************************************************************

LR_IROM1 0x08000000 0x00200000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00200000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  RW_IRAM1 0x20000000 0x00030000  {  ; RW data
   .ANY (+RW +ZI)
   *(.ram1)
  }
  RW_IRAM2 0x10000000 0x00010000  {  ; CCM
   .ANY (+RW +ZI)
  }
}

The __attribute__ directive

With the previous scatter file I have used the __attribute__ directive as following:

ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] __attribute__((section(".ram1")));
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] __attribute__((section(".ram1")));

In this way the 2 arrays are always allocated in the addresses interval:
[0x20000000, 0x20030000]

---

My real need is to avoid that the Ethernet DMA controller have to access to CCM memory, because it can't. This goal is reached if the previous arrays (DMARxDscrTab and DMATxDscrTab) are not allocated in CCM.

To get more details about this topic see this other post.