STM32U535 Backup registers access wait states

[GeertL]

Hi all, 

I am running into an issue related to writing backup registers on the STM32U535xx MCU. When I compile my code with -Oz, the write fails, whereas with -Os, it succeeds. The relevant C code is pretty straightforward:

LL_PWR_EnableBkUpAccess();
LL_RTC_BKP_SetRegister(RTC, LL_RTC_BKP_DR0, value);
LL_PWR_DisableBkUpAccess();

I ended up comparing the output assembly of the two compiler levels and found the cause below:

Left is compiled with -Oz and is not working (the write is not performed). Right is compiled with -Os and works as expected. The instruction labeled "store" is the STR operation which writes to TAMP->BKP0R. The instruction labeled "lock" writes to PWR->DBPR (disabling access to the backup domain).

As you can see, with -Oz there are 2 instructions between the "store" and "lock" operations, whereas with -Os there are 3. Indeed, when I add a __NOP() before the LL_PWR_DisableBkUpAccess() call, then it works as expected even with -Oz. Lowering the sysclk from 160 MHz down to 16 MHz does not change the situation. This seems to indicate that a write to the backup registers requires 3 additional wait cycles on this controller.

The same code ran on an STM32U575xx works as expected, even with only 2 instructions between the "store" and "lock" instructions.

I was not able to find any information regarding backup register latency in the STM32U5 reference manual, datasheet or device errata. However, I did find a presentation for STM32C0 which indicates that backup register writes do require 3 extra wait cycles. Is this also the case on STM32U535xx? Are there other STM32 controllers where this is a known issue?

 

[STOne-32]

Dear @GeertL ,

Thank you very much for the detailed description, it is very clear . We logged it in with this tracking number #177856 and next week we will be back to you . My guess it is the synchronisation between different Power domains and AHB buses. In older families it was mapped on APB bus , so the more AHB/APB ratio the more cycles are required to be propagated to the backup registers . The best to ensure an effective write is to make a read just after . It will ensure the write independently from compilers options or adding cycles . We will be back to You the soonest with my colleagues .

Have a great weekend 

STOne-32

[Stassen.C]

Hi GeertL,

Can you confirm that you used the same compiled code?

 

Regards,
Stassen

[GeertL]

Hi Stassen,

The C code in the OP is an abridged version (in the full version there are a few more things between LL_PWR_EnableBkUpAccess() and LL_RTC_BKP_SetRegister(), which are not relevant for the example).

I can confirm that the two assembly versions shown were compiled from the exact same C code. The only differences between the two assembled binaries was that I changed the compiler optimization level for specifically the file containing these function calls. For all other files in the project the compiler optimization level was unchanged.

I can also confirm the exact same C code compiled for STM32U575xx (specifically a Nucleo-U575ZI) did not exhibit the described issue with -Oz optimization level.

Specifically I am using Keil uVision 5.38 with ARM Compiler 6.19 with Link-Time Optimization enabled.

[Douglas MILLER]

This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.