cancel
Showing results for 
Search instead for 
Did you mean: 

Backup registers - using them to detect power issues: Will this work?

SKled.1
Senior II

Using a STM32F091.

I was thinking whether one could detect certain kind of boot / power issues where the VDD would be briefly interrupted, by buffering the VBAT with a sufficiently big capacitor, separated by a diode with low Vforward from VDD, so the cap won't get sucked dry by the rest of the circuit when VDD fails.

Is this a common thing to do / makes sense? (given that the system cannot have a battery to permanently power VBAT)

I also wonder what happens when I write to a backup register and inmidst of it, VDD fails.

Is there a way to make use of the backup registers to detect boot loop / power instability issues reliably? Garbled register content would not help so much.

I was thinking of a scheme like this to deal with that:

I use 2 of the backup registers as a double buffer (i.e. for each next frame, the other one of the two gets written) for a time value (that I get from a connected I2C total runtime counter chip). I use a 3. register as an index as to which of the two is the current one. This index is always written after the time value.

What I am attempting with this is that: If power fails while writing the index, it will have some weird value, not 0 or 1. So I assume that power failed writing that, and that the 2 time values must be valid, because power did not fail writing them, so the bigger one of the two is the current one (highest amount of runtime). If the index has a valid value, it must point to the last validly written time value. If writing to a time value failed because power was lost, it didn't yet get to writing the index, which is why the index is still good, even though it points to a slightly older value.

So when booting, I could compare the currently read out total runtime value with the one of the backup register and so determine whether the application had been running for only a brief moment.

Using another of the registers as a counter for this scenario, I would see whether very brief running periods of the app before a reboot happen and repeat, and thus refrain from turning on any devices that might cause power problems and instead go straight into error state.

Would this work, or, even if so, is this a good way?

1 ACCEPTED SOLUTION

Accepted Solutions
Uwe Bonnes
Principal III

Power outage issues are best tested by inspecting RCC_CSR reset flag. Look if the devices has brwon-out detection and PVD.

View solution in original post

2 REPLIES 2
Uwe Bonnes
Principal III

Power outage issues are best tested by inspecting RCC_CSR reset flag. Look if the devices has brwon-out detection and PVD.

SKled.1
Senior II

Ah, I was looking for "brown" keyword in the PDF and didn't see anything and put that aside. But it does have PVD, wasn't familiar with that, thanks.