Incorrect RAM_start (__ICFEDIT_SE_region_RAM_start__) at 0x20018000 for NUCLEO-G474RE SBSFU examples?

[MSand.5]

In the v2.6.2 NUCLEO-G474RE SBSFU examples 1_Image and 2_Image the linker file n_Image\Linker_Common\STM32CubeIDE\mapping_sbsfu.ld has the following line:

__ICFEDIT_SE_region_RAM_start__    = 0x20018000;

But the RAM actually starts at 0x20000000. Examples for other dev kits start at 0x20000000. Once I replace the example app with my real app, I have a linker error because I have run out of RAM.

Is this an error in the example or is there something special about the STM32G474 RAM above 0x20018000 that makes the SBSFU example want to use only that region?

[Bubbles]

Hi @MSand.5​,

the memory usage figure in UM2262, the official documentation, is not very clear. In that picture the SRAM start, address 0x2000 0000 is in the bottom. That's the part used by your application. The region starting at 0x20018000 is "SE" - used by the secure engine.

I'm afraid the linker is trying to tell you that your application doesn't fit in the region between 0x2000 0000 and 0x20018000. Check the generated map file to see what's the memory use.

BR,

J

[MSand.5]

thanks you for your quick response,

For the NUCLEO-G474RE, I'm not seeing the application RAM at lower addresses.

<>\STM32CubeExpansion_SBSFU_V2.6.2\Projects\NUCLEO-G474RE\Applications\1_Image\Linker_Common\STM32CubeIDE\mapping_sbsfu.ld

/* RAM section */
/* SE RAM1 region protected by MPU */
/* SE stack is placed 1st in RAM, stack overflow does not write on other RAM area */
__ICFEDIT_SE_region_RAM_start__ = 0x20018000;
__ICFEDIT_SE_region_RAM_stack_top__ = 0x20018400;
__ICFEDIT_SE_region_RAM_end__ = 0x20018FFF;

and

<>\STM32CubeExpansion_SBSFU_V2.6.2\Projects\NUCLEO-G474RE\Applications\1_Image\1_Image_UserApp\STM32CubeIDE\STM32G474RETx.ld

APPLI_region_RAM_start = __ICFEDIT_SE_region_RAM_end__ + 1;
APPLI_region_RAM_length = 0x2001B000 - APPLI_region_RAM_start;

So the application RAM runs from (0x20018FFF + 1) to 0x2001B000

Compare that to the NUCLEO-L476RG example

/* RAM section */
/* SE RAM1 region protected by firewall */
/* SE stack is placed 1st in RAM, stack overflow does not write on other RAM area */
__ICFEDIT_SE_region_RAM_start__ = 0x20000000;
__ICFEDIT_SE_region_RAM_stack_top__ = 0x20000400;
__ICFEDIT_SE_region_RAM_end__ = 0x20000FFF;

and

APPLI_region_RAM_start = __ICFEDIT_SE_region_RAM_end__ + 1;
APPLI_region_RAM_length = 0x20018000 - APPLI_region_RAM_start;

So in this case the application RAM is from 0x20001000 to 0x20018000

It looks like for the STM32G474RE example the SBSFU and application are both using this RAM

From the datasheet 3.5

32 Kbytes mapped at address 0x1000 0000 (CCM SRAM). It is accessed by the CPUthrough I-Code/D-Code bus for maximum performance.It is also aliased at 0x2001 8000 address to be accessed by all masters (CPU, DMA1, DMA2) through SBUS contiguously to SRAM1 and SRAM2. The CCM SRAM supports hardware parity check and can be write-protected with 1-Kbyte granularity.

And for the STM32L476RG example the SBSFU and application are both using this RAM

From the datasheet 3.5

96 Kbyte mapped at address 0x2000 0000 (SRAM1)

So for the STM32G474RE, is there something special about the highest 32 Kbytes of RAM that means I should use it for SBSFU? And therefor move the application code from the high addresses where the example puts it to the unused lower addresses. Or should I move the SBSFU RAM to the lower addresses like the other examples?

thanks, Michael

[Bubbles]

Hi @MSand.5​ ,

There are several SRAM:

• SRAM1: 0x2000 0000 - 0x2001 3FFF
• SRAM2: 0x2001 4000 - 0x2001 7FFF
• CCM SRAM: 0x1000 0000 - 0x1000 7FFF and 0x2001 8000 - 0x2001 FFFF

See the reference manual:

“The CCM SRAM is aliased at address following the end of SRAM2 (0x2000 5800 for

category 2 devices, 0x2001 8000 for category 3 devices, 0x2001 8000 for category 4

devices), offering a continuous address space with the SRAM1 and SRAM2.�?

STM32G474 is a category 3 device

With the current SBSFU configuration, the firmware is using the 32 Kbytes CCM SRAM:

• Boot:
  • 0x2001 8000 - 0x2001 8FFF: Secure Engine
  • 0x2001 9000 - 0x2001 90FF: Secure memory activation code area
  • 0x2001 9100 - 0x2001 FFEF: SBSFU
  • 0x2001 FFF0 - 0x2001 FFFF Shared RAM for Image State Handling
• Run time:
  • 0x2001 8000 - 0x2001 8FFF: Secure Engine
  • 0x2001 9000 - 0x2001 FFEF: User Application
  • 0x2001 FFF0 - 0x2001 FFFF Shared RAM for Image State Handling

The CCM SRAM is far more secure than the other ones:

• “On the Category 3 and Category 4 devices, a parity check is implemented on the first

32 Kbytes of SRAM1 and on the whole CCM SRAM.�?

• “CCM SRAM Write protection�?
• “The CCMSRAM is protected with the Read protection (RDP).�?
• “CCM SRAM erase�?

I would not recommend to use SRAM1 or SRAM2 for SE and/or SBSFU.

Regarding the user application, you can use SRAM1 and SRAM2 as long as you accept that these SRAM don’t have security features on same level as CCMSRAM.

You should not need to change MPU configuration to place your user app to SRAM1 or SRAM2.

BR,

J

[MSand.5]

thank you. I'm porting an existing application to SBSFU and the RAM usage just didn't fit in the remainder of the CCM RAM. I will leave the SBSFU in there and move the application down to the lower address RAM areas. This is different than all dev-kit examples in the SBSFU package, but those example applications don't use much RAM.

[Bubbles]

Hi @MSand.5​,

I contacted the example developers and they always try to fit the example to the most secure memory, leaving the option to move part of the app to less secure memory up to the customer.

IDK if it makes sense to you to keep part of your app in the CCMSRAM.

BR,

J