2026-05-13 1:29 AM
(and why is this a problem?)
It looks like the backup ram can not be called through unaligned access on my STM32U585. The mighty internet says that this should not be completely unexpected since it is basically a peripheral and no standard Ram.
I have set up the BKPSRAM in the linker file like this:
#include "partition.h"
/* Entry Point */
ENTRY(Reset_Handler)
/* Highest address of the user mode stack */
_estack = ORIGIN(RAM) + LENGTH(RAM); /* end of "RAM" Ram type memory */
_Min_Heap_Size = 0x000 ; /* required amount of heap */
_Min_Stack_Size = 0x800 ; /* required amount of stack */
/* Memories definition */
MEMORY
{
BKPSRAM (xrw) : ORIGIN = 0x40036400, LENGTH = 2K
SRAM4 (xrw) : ORIGIN = 0x28000000, LENGTH = 16K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = NON_SEC_RAM_SIZE /* Secure is using end RAM3 (64k). Actual start is 0x20000000 and actual length is 768K */
FLASH (rx) : ORIGIN = 0x8000000 + APP_SLOT0_NON_SEC_APP_OFFSET, LENGTH = NON_SEC_APP_SIZE /* Memory is divided. Actual start is 0x08000000 and actual length is 2048K */
}
/* Sections */
SECTIONS
{
...
/* backup ram area */
BKUP_RAM(NOLOAD):
{
. = ALIGN(8);
*(BKUP_RAM)
*(BKUP_RAM*)
. = ALIGN(8);
}>BKPSRAM
...The respective variables are moved in the section BKUP_RAM accordingly.
Compiler is the arm GCC toolchain 14.2.
I have found out that I can solve this with -mno-unaligned-access for the complete project, but of course this means missed optimization through the whole project. Is there a way to only mark the specific section/variables instead?
2026-05-13 2:28 AM
> It looks like the backup ram can not be called through unaligned access on my STM32U585.
What is "called through unaligned access" exactly, and how do you know that it's a problem?
I don't use the 'U5, but Cortex-M33 does support unaligned accesses at both its ports by splitting them to aligned accesses, and BKPSRAM is at an AHB bus which should support all alignments.
Note, that in 'U5, BKPSRAM *does* have ECC.
JW
2026-05-13 2:37 AM
+ From PM0264:
2026-05-13 2:39 AM - edited 2026-05-13 2:41 AM
As you can see in the screenshot there is a str to 0x40036452 which leads to an unaligned access hard fault. Which is not present if I compile with -mno-unaligned-access or place the variables in standard SRAM.
Considering the bus used, the reference manual states
CPU can access the SRAM4 and BKPSRAM through the system bus only. And as the programmers manual says some memories might not support unaligned access."
At least unaligned access is what the hard fault analyzer states. But ECC might be an issue when initializing the "no load" ram cells with values which are no multiples of its granularity :thinking_face:, that's right.
2026-05-13 2:42 AM
As shown by PM0264, the "STR" instruction is supported by the unaligned access.
2026-05-13 2:48 AM - edited 2026-05-13 2:59 AM
Well using that specific memory the hardware doesn't seem to agree. But I'll look into the ECC topic.
EDIT: ECC is turned off (flag = 1) in the option bytes and UNALIGN_TRP ist not set.
2026-05-13 6:52 AM
I've looked into the Cortex-M33 TRM, and it has this to say:
Any unaligned access that is not faulted by the alignment restrictions and accesses Device
memory has UNPREDICTABLE behavior. In the Cortex®-M33 processor, accesses of this type
generate an UNALIGNED UsageFault exception.
The default MPU map indeed sets the 0x4000'xxxx area as Device.
Do you set MPU or leave it at default?
Now how does this match your finding, is not clear to me.
JW