STM32F405 BKPSRAM Random values after initialize

[Jan Wustrau]

Hello,

I have a strange issue with backup ram in F405. It is battery powered after main power off.

When i remove battery and power up board, whole bkpram contains values of 0 - this is normal. But after initialize procedure whole memory contains random values.

This is very strange, because during normal work (with battery connected) i can write data to it, switch power off and all my data remains after next power up.

It's my initialize function:

 

	RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);
	RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_BKPSRAM, ENABLE);
	PWR_BackupAccessCmd(ENABLE);
	PWR_BackupRegulatorCmd(ENABLE);

	while ((PWR->CSR & (PWR_FLAG_BRR)) == 0);

 

[waclawek.jan]

> When i remove battery and power up board, whole bkpram contains values of 0 - this is normal.

No. The backup-domain reset does not clear BKPSRAM, see RM. Power removal (i.e. both VBAT and VDD) and restore brings the BKPSRAM up with random content.

What you see as all zeros is consequence of the BKPSRAM not having clock enabled in RCC.

You can try it yourself: with the battery installed and BKPSRAM properly initialized and filled up with your data, disable is clock in RCC and try to read it. Then reenable the clock and try to read it again. You don't need to write code for this, you can experiment in debugger. 

JW

[Jan Wustrau]

Thank you for your explanation.

My test was by uploading firmware with a while(1); before initialization so that after VBAT and VDD reset, the program wouldn't execute anything.
So, I understand that in such a case (as long as the firmware doesn't enable the clock), neither the STM32CubeIDE debugger nor ST-Link (with STM32CubeProgrammer) are not able to read that memory?

 

I have one more question. What is the reason (probably physical) that this memory gets a random values after a power loss?

[waclawek.jan]

> So, I understand that in such a case (as long as the firmware doesn't enable the clock), neither the STM32CubeIDE debugger nor ST-Link (with STM32CubeProgrammer) are not able to read that memory?

Yes.

CubeProgrammer allows to access registers, though, as a memory area, so you can circumvent this problem, as described here. It's somewhat impractical to do it manually except for experimenting, but may be quite feasible in a script through the CLI.

> What is the reason (probably physical) that this memory gets a random values after a power loss?

Every SRAM does this, unless it has some extra circuitry which would reset it to a defined state.

Basis of the SRAM cell is the classic two-transistor flip-flop, where one transistor's gate is connected to the other's drain, and vice versa (https://en.wikipedia.org/wiki/Static_random-access_memory#/media/File:SRAM_Cell_(4_Transistors).svg - M1 and M2; M3 and M4 are transistors  which facilitate read/write). This circuit has a "self-enforcing" property (a form of positive feedback) which holds it in one of the two stable states (until disturbed externally through said read/write transistors): if M1 is open, it's drain is at ground and that holds M2 closed, which means that its drain is high and that holds M1 open - vice versa for the other state.

When this cell is brought up from powered-down state, the voltages on the drains/gates rise, and as there is always some miniscule disbalance in the two transistor's threshold voltage, one of them - let's assume M1 - starts to conduct sooner than the other. That creates a current through M1 which decreases voltage on M1's drain thus M2's gate, and that closes somewhat M2 which in turn increases voltage at its drain thus at M1's gate... and so fort, in a positive feedback style, until M1 opens completely and M2 closes completely.

So the reason for the "randomness" are the miniscule differences in individual transistors' threshold voltages. These depend on manufacturing process variations (MOSFET oxide thickness, distribution of intended (deliberately diffused/implanted) and unintended impurities in silicon), and also temperature distribution at the moment of switching on. So, this is not entirely "random" and there is usually some degree of correlation between content of RAM read out after individual powerup cycles (in other words, you should not rely on this process to generate randomness).

JW

[Jan Wustrau]

Thank you.