How to prevent unaligned access on backup ram?

> 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

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.

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

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.

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

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

Ok, so to reiterate:

• M33 (and older devices as well?) always has an active MMU (!)
  • MPU disabled means MMU is running with default memory map
• The default memory region in STM32U5 defines the complete 0x40000000 - 0x60000000 region as peripherals and therefore device memory 
• BKPSRAM is inside the Peripheral Address range, so the default map puts it as device memory
• To use BKPSRAM as "normal" memory, the MPU needs to be enabled and its region defined specifically

Is this the gist of it?

In code I now use the following and that seems to solve my issue:

static void initMpu(void)
{
 // 1. Select MPU Region Number
 MPU_NS->RNR = 0;
 //2. define an attribute type which matches normal memory
 MPU_NS->MAIR0 = 0x00000033;
 // 3. Set Base Address, Access Permissions (Read/Write)
 MPU_NS->RBAR = (0x40036400 & MPU_RBAR_BASE_Msk) |
 (0x01UL << MPU_RBAR_AP_Pos);// Read/Write for Privileged and Unprivileged

 // 4. Set Limit Address, Link to Attribute 0 (ATTR0), and Enable Region
 MPU_NS->RLAR = ((0x40036400 + 0x800 -1) & MPU_RLAR_LIMIT_Msk) |
 (0x0UL << MPU_RLAR_AttrIndx_Pos) | // Link to ATTR0 (Normal memory)
 (0x1UL << MPU_RLAR_EN_Pos); // Enable this MPU region
 //5. enable the MPU, keeping the default map in the background
 MPU_NS->CTRL |= (0x1UL << MPU_CTRL_ENABLE_Pos) | (1UL << MPU_CTRL_PRIVDEFENA_Pos);
}