STM32H743: Backup RAM not saved

[PMath.4]

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

[waclawek.jan]

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

[PMath.4]

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]

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 · Accepted solution]

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]

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

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]

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.

[waclawek.jan]

Maybe you should start a new thread, describing the hardware, details of what have you tried so far and what were the results.

JW

[CLadd.1]

I will. Thank you.