stm32h533re execute code in sram1

[jhoerd]

Hello members,

Until recently, I was using a G473. There, I ran code from the ccmram. That worked without any problems. Now I have switched to the H533. For performance reasons, I want to run the code in SRAM1 0x20000000 - 0x2001FFF. I want to keep the data in SRAM2.

MEMORY
{
RAM (xrw) : ORIGIN = 0x20020000, LENGTH = 80K /*Ram placed SRAM2 with ECC-Check*/
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 256K
CCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K /*SRAM1 for code */
}

For example, the function:

__attribute__((section(“.ccmram”))) void EXTI0_IRQHandler();

is located in the map file at the correct address:

.text.EXTI0_IRQHandler
0x0000000020000300 0x28 ./Hal/Interface/Interrupts.o
0x0000000020000300 EXTI0_IRQHandler

The code is copied to SRAM1 in the startup file.

However, when I call the function, a hard fault is generated.
The PC points to the address: 0x20000302
The CFSR register contains: 0x01000000, which
corresponds to UFSR[8] and means unaligned access. This would match the pc address: 0x20000302.

Now my question: Is there an easy way to allow unaligned access in SRAM1? For example, by configuring the MPU or by remapping SRAM1 to 0x10000000, for example. In my research so far, I have not found a solution that works for me.
(I am using CubeIde with gcc)

Thanks in advance

jhoerd

 

[NesrynELMK]

Hello @jhoerd 

Please take a look at this article: https://community.st.com/t5/stm32-mcus/how-to-place-and-execute-stm32-code-in-sram-memory-with/ta-p/49528

It provides a detailed explanation on how to execute the entire firmware directly from embedded SRAM memory.

 

 

Kind regards,

[jhoerd]

Hello NesrynELMK,

Thank you very much for your reply. I am only responding now because I did not know how to describe my problem more specifically.
I was already familiar with the example you mentioned. However, it does not apply to my specific use case or problem. While trying to describe my problem better, I came up with the solution.

I am using CubeIde with gcc and SRAM2 for data and SRAM1 for code.

Two fundamental problems arose in my example.
1. Alignment of static, global variables
When calling:
/* Call static constructors */
bl __libc_init_array
in StartupFile.s, a hard fault occurred. This error was due to alignment in the memory area for few global static variables.
This was resolved by using the aligned(4) attribute.
__attribute__(( aligned(4))) type1 variable1;

2. alignment von code in sram1
I place vector table and code in sram1 using the following linker instruction:

_sivector = LOADADDR(.isr_vector);

.isr_vector :

{

. = ALIGN(4);

KEEP(*(.isr_vector)) /* Startup code */

. = ALIGN(4);

} >CODERAM AT>FLASH

.coderam :

{

. = ALIGN(4);

_scoderam = .;

*(.coderam)

*(.coderam*)

*/sampleFile.o(.text .text*)

. = ALIGN(4);

_ecoderam = .;

} >CODERAM AT>FLASH

A bus fault was triggered during the execution of the code. While investigating the error, I noticed the following in the linker map file:

*(.isr_vector)
.isr_vector 0x0000000020000000 0x254 ./startupH523x.o
0x0000000020000000 g_pfnVectors
0x0000000020000254 . = ALIGN (0x4)

.coderam 0x0000000020000258 0xef8 load address 0x0000000008000254
0x0000000020000258 . = ALIGN (0x4)
0x0000000020000258 _scoderam = .

//content

//at end of codeRam area:

0x0000000020001090 0xc0 linker stubs
0x0000000020001150 . = ALIGN (0x4)
0x0000000020001150 _ecoderam = .
0x000000000800114c _sidata = LOADADDR (.data)

The offset of -4 at the end and +4 at the beginning of the codram area seemed suspicious to me.

I changed the alignment specification in the linker script as follows:

_sivector = LOADADDR(.isr_vector);

.isr_vector :

{

. = ALIGN(4);

KEEP(*(.isr_vector)) /* Startup code */

. = ALIGN(8);

} >CODERAM AT>FLASH

.coderam :

{

. = ALIGN(8);

_scoderam = .;

*(.coderam)

*(.coderam*)

*/sampleFile.o(.text .text*)

. = ALIGN(8);

_ecoderam = .;

} >CODERAM AT>FLASH

This removed the offset from the map file.

.isr_vector 0x0000000020000000 0x254 ./startupH523x.o
0x0000000020000000 g_pfnVectors
0x0000000020000258 . = ALIGN (0x8)
*fill* 0x0000000020000254 0x4

.coderam 0x0000000020000258 0xef8 load address 0x0000000008000258
0x0000000020000258 . = ALIGN (0x8)
0x0000000020000258 _scoderam = .

//at end of codeRam area:

0x0000000020001090 0xc0 linker stubs
0x0000000020001150 . = ALIGN (0x8)
0x0000000020001150 _ecoderam = .
0x0000000008001150 _sidata = LOADADDR (.data)

This means that my code now also works in the SRAM area without any problems.

Perhaps my insight will also help others who have a similar problem.

How do I mark the thread as resolved?
Thanks again for your help.

best regards

jhoerd