Writing to STM32F767 battery backed SRAM, why can't I turn on PWR->CSR1 BRE

[Oliver Sedlacek]

I need to write to the 4kB battery backed SRAM to hold information across power cycles, but it's not working! To be more specific:

1. The debugger memory display shows the correct data in SRAM after a write.
2. The data is read successfully at any time other than after a power cycle e.g. after a reset.
3. The battery is keeping the RTC alive and well.
4. I've set up an MPU region to make the 4kB at 0x40024000 non-cacheable

Here's my code for writing to BB SRAM:

// Now write it to BB SRAM
 RCC->APB1ENR |= RCC_APB1ENR_PWREN; // Enable power interface clock by setting the PWREN bit 
 PWR->CR1 |= PWR_CR1_DBP; // Disable write protection 
 RCC->AHB1ENR |= RCC_AHB1ENR_BKPSRAMEN; // Enable the backup SRAM clock by setting BKPSRAMEN
 __DMB(); 
 memcpy((void *)pSRAM, &pay, len + sizeof(uint16_t));
 __DMB(); 
 SCB_CleanDCache();
 reg = RCC->AHB1ENR; // definig reg as volatile forces a read
 RCC->AHB1ENR &= ~RCC_AHB1ENR_BKPSRAMEN;
 PWR->CR1 &= ~PWR_CR1_DBP;
 RCC->APB1ENR &= ~RCC_APB1ENR_PWREN;

As you can see, I'm throwing everything at beating the cache but still no joy.

[waclawek.jan]

When the backup domain is supplied by V BAT (analog switch connected to V BAT because

V DD is not present), the backup SRAM is powered by a dedicated low-power regulator. This

regulator can be ON or OFF depending whether the application needs the backup SRAM

function in Standby and V BAT modes or not. The power-down of this regulator is controlled

by a dedicated bit, the BRE control bit of the PWR_CSR1 register

Quoting from 'F746 RM as I was lazy to download a 'F767 RM, but it will be the same.

JW

[Oliver Sedlacek]

Jan, that looks like it! It's taken me a while to figure out what's stopping me from turning BRE on! I can't see it in the manual but you need to set PWR->CR1 DBP before you can set BRE.

BTW did you use to hang out on www.8052.com?

[waclawek.jan]

Sure I did.

It's www.8052mcu.com now, and still alive, or, zombie-like.

Jan

[Danish1]

Power-cycle is NOT the same as reset.

Reset just sets specific things to certain states. Anything else is left unchanged.

Power-cycle means any other RAM values could be in random states. If you only lost power for a short time, many of the bits in RAM could be unchanged. But losing power for a longer time means that a higher proportion of bits will be scrambled.

How strongly do you know that it is the cache you are having to fight? Does it (for example) work if you never enable the data cache?

You have not shared the code of where you try to read the backup SRAM. Do you make sure you have enabled RCC->AHB1ENR |= RCC_AHB1ENR_BKPSRAMEN; beforehand?

Hope this helps,

Danish

[Oliver Sedlacek]

Hi Danish, thanks for your input. I'm well aware of the differences between Reset and a power cycle, but that's kind of the point of battery backed RAM. I didn't post read code because reads work fine and my code and the debugger agree on what's in there.

[Danish1]

From what I can see, you say that when you write then read back, what you wrote was read back correctly.

But when you read back before having written (for the value to persist over reset and power-down-with-battery-backup) you do not read the last-stored value.

So what I was raising was the possibility that the write, or other things that happen leading up to the write, leave the processor and its peripherals in a state where it is able to read things back.

What value do you read when it doesn't work? Is it always the same value?

The data cache won't give a cached value if (since the reset) that memory-location has never been read.

You might get a value suggests "there's no peripheral at this memory location" if you've never enabled power/access to the BBSRAM or never enabled its clock.

But you might also get a value e.g. 0 that suggests that your C compiler is unhelpfully clearing out memory for all static variables prior to entering main().

[waclawek.jan]

> Now I just need to figure out what's stopping me from turning BRE on!

Do you have enabled clock for PWR in RCC?

You may perhaps also want to add some delay after the clock enable, before accessing PWR.

JW

[Oliver Sedlacek]

I've edited my earlier post, but just to re-iterate you need to set DBP in CR1 before you can set BRE

[waclawek.jan]

Oliver,

Nice catch!

> I can't see it in the manual but you need to set PWR->CR1 DBP before you can set BRE.

It is documented, sort-of, but not where you'd expect it:

@Imen DAHMEN​ ,

Can please all relevant ('F2, 'F4, 'F7) RMs be updated so that the description of the PWR_CSR(1).BRE bit contains a text, outlining that this bit is in the backup domain and thus DBP has to be set before being able to write into it?

Thanks,

Jan

[Imen.D]

Hello @Community member​ ,

Thank you for bring this to my attention.

I will forward your feedback internally to look into.

Best Regards,

Imen

[waclawek.jan]

Thanks, Imen.

Jan