Skip to main content
PMath.4
PMath.4
Senior III
November 9, 2019
Solved

STM32H743: Backup RAM not saved

  • November 9, 2019
  • 12 replies
  • 8325 views

I'm trying to use the 4K backup RAM on the STM32H743. The RTC is working and keeps time so I know the battery system is OK. I can read and write to the backup RAM OK but it loses all data on power off.

I've enabled access as follows:

HAL_PWREx_EnableBkUpReg();
 HAL_PWR_EnableBkUpAccess();

The code behind these is trivial

SET_BIT(PWR->CR1, PWR_CR1_DBP);

and

SET_BIT(PWR->CR2 PWR_CR2_BREN);

  

The C source for stm32h7xx_hal_pwr.c has the following comment:

"     After reset, the backup domain (RTC registers, RTC backup data

     registers and backup SRAM) is protected against possible unwanted

     write accesses.

     To enable access to the RTC Domain and RTC registers, proceed as follows:

       (+) Enable the Power Controller (PWR) APB1 interface clock using the

           __HAL_RCC_PWR_CLK_ENABLE() macro.

       (+) Enable access to RTC domain using the HAL_PWR_EnableBkUpAccess() function.

"

but __HAL_RCC_PWR_CLK_ENABLE() does not exist for the H7 and looking at the reference manual there is no obvious bit to set in the clock enable registers. There is a relevant bit on the F4 and the two commands do different things on the F4 but of course the registers have completely different names

*(__IO uint32_t *) CSR_BRE_BB = (uint32_t)ENABLE;
*(__IO uint32_t *) CR_DBP_BB = (uint32_t)ENABLE;

Any help appreciated

This topic has been closed for replies.
Best answer by PMath.4

Got there eventually. The set up sequence is:

 __HAL_RCC_BKPRAM_CLK_ENABLE();
 HAL_PWREx_EnableBkUpReg();
 HAL_PWR_EnableBkUpAccess();

but then the critical issue is that it is essential to ensure the data get flushed from the cache

void writetobackup(uint64_t *padd, uint64_t data){
 	*padd = data;
 padd = (uint64_t *)((uint32_t)padd & 0xFFFFFFE0);
 SCB_CleanDCache_by_Addr((uint32_t *)padd, 32); ' minimum cache flush is 32 bytes
}

12 replies

waclawek.jan
waclawek.jan
Super User
November 9, 2019

If you can write and read the memory, you don't need to be bothered by PWR clock, PWR may have a fixed clock (i.e. not gateable) in H7 - I am not interested in H7 to be bothered to look it up. The rest in Cube - doubled functions and the comment on PWR clock - is for historical/backward-compatibility reasons and copy/past thing.

How is VBAT connected?

 Do you use Tamper in RTC?

RDP change can clear the BkpSRAM, too.

JW

shravanhudekar
Associate
June 22, 2023

 

I am also facing same issue.

VBAT connection is proper as I am able to retrieve data and time in backup register.

Tamper detection is disabled.

RDP is also not used.

PMath.4
PMath.4Author
Senior III
November 9, 2019

How is VBAT connected?

CR1220 between VBAT and GND. Works fine for RTC and RTC backup registers

Do you use Tamper in RTC?

No

RDP change can clear the BkpSRAM, too.

I'm not knowingly doing anything with RDP but I do write to flash so I call HAL_FLASH_Unlock();

Is it possible that when I write then read from 0x3880000 I'm just accessing the cache and the RAM is never geting updated because it is protected?

Danish1
Danish1
Lead III
November 9, 2019

Your register access doesn't look right. E.g. to enable access to the backup SRAM you'd do something like

PWR->CR1 |= PWR_CR1_DBP;

Hope this helps,

Danish

PMath.4
PMath.4AuthorBest answer
Senior III
November 9, 2019

Got there eventually. The set up sequence is:

 __HAL_RCC_BKPRAM_CLK_ENABLE();
 HAL_PWREx_EnableBkUpReg();
 HAL_PWR_EnableBkUpAccess();

but then the critical issue is that it is essential to ensure the data get flushed from the cache

void writetobackup(uint64_t *padd, uint64_t data){
 	*padd = data;
 padd = (uint64_t *)((uint32_t)padd & 0xFFFFFFE0);
 SCB_CleanDCache_by_Addr((uint32_t *)padd, 32); ' minimum cache flush is 32 bytes
}

    waclawek.jan
    waclawek.jan
    Super User
    November 9, 2019

    Humm. It wouldn't occur to me that the BKPSRAM area is cacheable by default; I'd expect it to be amidst the peripheral registers.

    JW

    Pavel A.
    Pavel A.
    November 9, 2019

    Confirmed on H753-eval2 board. The cache flush is needed to get the write data thru.

    Maybe a better solution is to set up a MPU region for the backup RAM.

    -- pa

    CLadd.1
    CLadd.1
    Visitor II
    March 18, 2021

    Has anyone gotten a solution using the MPU so that the cache flush is not required? I am trying to use both the internal backup RAM and have a 1Mb external battery backup SRAM that I need to write through to randomly with thousands of process points. I am going to use the internal to replace some internal EEPROM from another manufacture NXP, so the flush is not a problem. The external backup ram is accessed all over our application in to different 5Khz interrupts. We need a write through solution to this memory and was hoping to configure the MPU to do it, but have not been successful in our attempts.

    shravanhudekar
    Associate
    June 22, 2023


    __HAL_RCC_PWR_CLK_ENABLE();
    HAL_PWR_EnableBkUpAccess();
    __HAL_RCC_BKPRAM_CLK_ENABLE();

    // Enable backup regulator
    HAL_PWREx_EnableBkUpReg();
    // Wait until backup regulator is initialized
    while (!LL_PWR_IsActiveFlag_BRR());

    I have used above methods to initialization of Backup domain.

    On VDD I am able to read and write on SRAM successfully and even on soft reset data is not lost.

    but when device goes into power down (VBAT connected to RTC) data is lost when checked on next power cycle.

    RDP, temper detection and cache is disabled.

     

    waclawek.jan
    waclawek.jan
    Super User
    June 22, 2023

    Please don't hijack other's threads.

    Start your own thread, perhaps giving link to this one; stating the STM32 model you are using, what hardware/board (Disco/Nucleo/your own) are you using, what is the VBAT connection, and how exactly do you arrive at the problem you are describing.

    JW

    Terms & ConditionsAccessibility statement