How to prevent unaligned access on backup ram?

[OliM]

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

[waclawek.jan]

> 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

[mƎALLEm]

+ From PM0264:

[OliM]

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.

[mƎALLEm]

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

[OliM]

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]

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

[OliM]

First of all thank you very much for digging through this with me @waclawek.jan 
MPU is disabled, but your finding does somehow reflect what I am seeing: The controller/core is not happy about unaligned access to that "device" memory region. 
Which I would be kind of fine with, if I found a way to tell that to gcc.

[waclawek.jan]

As I've said I don't use the 'U5 and for that matter, any Cortex-M33-based STM32 either.

However, I looked into ARMv7M ARM(*) for Cortex-M4, and it says, in A3.5.5 Device memory:

Any unaligned access that is not faulted by the alignment restrictions and accesses Device memory has
UNPREDICTABLE behavior.

i.e. unlike ARMv8M it does *not* fault in this case, it's unpredictible i.e. may fail silently as well as work as expected in most of the cases, except that we don't know which are those cases when it won't...

Interesting. I am using BKPSRAM in 'F4 extensively and never came across any alignment issue, but I need to review the mapfiles whether there is any chance for unaligned access in my programs. This is new to me.

(*) Architectural Reference Manual - yes that resulted in confusing abbreviation, but it is what it is

---

You can enforce alignment of any variable in the same way as you assign it into a particular section: using attribute, namely aligned().

JW

[Pavel A.]

IIRC the Backup RAM has "device" type by default (in the MPU background region) also in F4 and maybe other families. Try to define it as normal, non-cached by the MPU, and see what happens. 

(I used the backup RAM in the F446 and H743, but out of laziness just copied it to normal RAM and manipulated there).