STM32H743 Battery backed ram issue - ideas wanted

[PMath.4]

I'm using the 4K of battery backed RAM on the STM32H743 to preserve variables between power cycles. This works fine on 90% of identical systems running identical firmware and with identical H/W, identical chip versions etc. i.e. data is exactly what it should be after power cycling. I always flush the cache after writing to the RAM as this is a known issue.

On a small percentage of systems the Backup RAM is completely overwritten and this is always to the same values. Obviously I've checked the batteries and the RTC keeps time after power cycling so I know the RTC power domain is OK.

I'm at a loss as to where to look for the problem - any ideas appreciated.

The initialisation code for the RAM is taken from the ST example code and as explained above on most versions of "identical" H/W with identical firmware works perfectly.

On all systems the RAM is correct after a reset, it is only after a power cycle that I see the problem

[Uwe Bonnes]

How often d you write to battery backed RAM. Maybe do not memory map, but use a function to read/write that memory and only enable the clock while in the function.

[Paul1]

1. Catch the false write

• Extremely important to find where/why the data is being corrupted, as this might indicate some other function is doing something wrong (like using a data pointer or index that was a functions internal stacked variable, orphaned and randomly corrupted sometime after function finished).
• You say it is always getting overwritten with same values, can you detect where in your code those repeatable values are being generated? Is there a pointer or index involved? Try making it static. Maybe a data copy (string/array/struct/table)? Try changing the data in the string or table to a recognizable pattern to verify it is the actual cause.

2. Robust with dual block

• Is it possible that the power is going out just as you are writing the block, and that is corrupting the block?
• Try a dual block scheme, like used for directories on disks.
• Block is data+Checksum. Block written twice.
• When read block first verify checksum, if corrupt then use second block.
• If a block is corrupt then rewrite it (Possibly by just copying other block).
• **Always overwrite the corrupt block before overwriting the remaining good block (else may end up with both blocks corrupt).
• Speed: Consider splitting block into 2 blocks for rarely and often written data, so faster checksum on the smaller often written block, while rarely written block is untouched (total now 4 blocks).

Paul

[Paul1]

3. If available catch "brownout" events or reset on brownout to prevent MCU from running on unreliable power.

[PMath.4]

Thanks for the ideas.

The backup ram is only being written very infrequently and only when the user actions a specific request from the UI. It is only written from a single function. As the backup ram is non-contiguous with other memory then any "rogue" write would likely trigger a bus error. Note also that the write survives a reset perfectly. It is something to do with the power-down/power-up sequence that causes the problem. I'll add a brown-out interrupt to immediately put the processor into reset but am not hopeful this will help

[waclawek.jan]

Most likely it's a program bug resulting in overwriting the backup RAM.

Is backup-domain write disabled all the time except when writing to the NVRAM/RTC?

Place a data breakpoint ("watchpoint") to the BKPSRAM and observe, what are the sources of writes.

JW