2025-08-12 12:59 AM - last edited on 2025-09-08 4:27 AM by mƎALLEm
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
Solved! Go to Solution.
2025-09-08 12:51 AM
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
2025-08-13 6:43 AM
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,
2025-09-08 12:51 AM
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