SRAM2 erased on backup domain reset

[PScal]

Hi @all,

we have an application, where we use the LSE. In due to weaknesses of the part we use, the LSE can fail sometimes.

If I then use the __HAL_RCC_BACKUPRESET_FORCE() and __HAL_RCC_BACKUPRESET_RELEASE() to reset the LSE and LSI system, also the SRAM2 section is deleted.

I don't understand why.

From the reference manual Rev.04 page 481 chapter 11.3.3 Backup domain reset it says: "A backup domain reset affects the LSE oscillator, the RTC, the TAMP, the backup registers, RCC_BDCR, and PWR_BDCR1. The reset of PWR_BDCR1 affects the backup SRAM."
The backup SRAM for me is only the BKPSRAM, or not? 
Also that sentence misses the LSI, if used. 

The tamper unit is not configured and not used at all. We have a STM32U575CIU6 Rev. X. I also did not found something within the errata sheet. Did I overlook something? 

Does anyone has a tip for me? Is there a configuration/register/bit I miss which gives the information if the SRAM2 shall be erased with a backup domain reset? 

[Aime]

Hi @PScal ,

The SRAM2 is contained in the Core domain,  in should not affected by the reset of the Backup domain which contains : the LSE, LSI, Backup registers, RCC_BDCR and PWR_BDCR1 registers, RTC, TAM and Backup RAM.

I understood that you are not using the tamper unit, then there is any System reset on your application? Are you entering in low power mode (Stop modes, Standby, Shutdown or Vbat)?

Best regards,

Aime

[PScal]

Hi @Aime ,

yes we use the low power standby mode and we also use ECC on SRAM2 (active by Flash Option Byte) so directly from the start. 

So for a better picture: 

On Power on start we initialise the backup domain to have LSE for RTC and LSI with a divider of 128 for IWDG. The LSE is also used for LPTIM2. The system switches then to low power standby. The external part for the LSE breaks and the low power standby is left by a wakeup reason in due to an external pin trigger event. Now the LSECSSD is set and with the startup (in due to the wakeup from low power standby) we reinitialize the low frequency system, trying to check if the fault still applies at the LSE. Therefore I use the backup domain reset and as soon as this is then triggered the SRAM2 is also erased. (Where we store the hole .data and .bss section as we want to have it ECC protected.)  

If we only will have system resets, the LSECSSD bit is never reset. Can I initialize the LSE having the LSECSSD bit active and would the LSE then have an active LSERDY and then clear the LSECSSD, so that it can be monitored again by LSECSSON? The only way I found is by a backup domain reset, so LSECSSD is cleard with everything else and I can start from scratch.

Best regards,
Peer

[Aime]

Hi @PScal ,

Thank for the description, I just want to check something. By default in Standby mode the contain of all SRAMs are lost unless you activate the RAM retention with the RRSB2 and RRSB1 bits in the PWR_CR1 register (the default value is 0x0000 0000) with the function HAL_PWREx_EnableSRAM2ContentStandbyRetention.  

Best regards,
Aime

[PScal]

Hi @Aime ,

that is not the case in the specific situation. The standby (with SRAM2 loss) is in that step of our process not used to recover the LSE/LSI. I have some code that forces the backup domain reset and already stepping through that code with the debugger I can see the SRAM2 been erase. SRAM1 and SRAM3 keep their content in that situation. After that I force a software reset. (No low power standby sleep there.) The standby is used within the rest of the application if the configuration of the LSE/LSI is over. 

Best regards, 
Peer

[Aime]

Hi @PScal ,

I escalated your issue, and on the revisions X and under a backup domain reset can erased the contain of the SRAM2. This is something that we fixed on the next revision W, For the errata sheet I asked to team to add this case and it should appear on the next version.
For now the only workaround that we have for the revision X is to avoid to use the backup domain reset instruction.

Best regards,
Aime

[waclawek.jan]

It's unsettling to find out that ST does not document all changes in silicon between revisions in the ES.

[EDIT]

This change has been specifically made in the RM:

And this is even more unsettling: the RM now deliberately incorrectly describes the behaviour of the Rev.X silicon.

Btw. the most recent Erratum which does not mention this change is dated March 2023, whereas the RM which does reflect it is dated February 2023...

JW

[PScal]

Hi @Aime,

thanks for the information. But how can I then get the LSECSSD bit reset? 

Best regards,
Peer

[STOne-32 · Accepted solution]

Dear @waclawek.jan ,

Thank you for pointing this miss, much appreciated, We confirm  that the behavior  will be added in STM32U5 Errata as already done in STM32H5 series here : STM32H562xx/563xx/573xx device errata - Errata sheet  in Limitation 2.2.14 SRAM2 is erased when the backup domain is reset  that describes how to safely erase SRAM2 and avoid corruption of data not in purpose ( done for example during startup) and more important to describe the behavior observed by @PScal . Now for recent revW, that behavior is changed and indeed Reference Manual Rev4 take it in charge with a delayed synchronization for the Errata as described by @Aime .

Hope now, the situation is more clear.

Cheers,

STOne-32.

[STOne-32 · Accepted solution]

Hi @PScal ,

Yes, Only way to get the LSECSSD bit reset is to apply the Backup domain reset.

We can for example safely reset SRAM2 or even before applying this Backup domain- reset to  save content of SRAM2 in another SRAM and after safe SRAM2 erase to restore the content.  another alternative is to get Rev W .

Hope it helps you to get the right picture.

Cheers,

STOne-32.