cancel
Showing results for 
Search instead for 
Did you mean: 

How to prevent unaligned access on backup ram?

OliM
Senior II

(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.

OliM_0-1778660195150.png

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?

6 REPLIES 6
waclawek.jan
Super User

> 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

 

+ From PM0264:

mALLEm_0-1778664719632.png

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
OliM
Senior II

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.

 

As shown by PM0264the "STR" instruction is supported by the unaligned access.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

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.

waclawek.jan
Super User

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