Can a write to the RTC battery backed register domain be corrupted (STM32G4) - Page 1
Forum section: electronics / general

author: uer166
author_rank: Super Contributor
timestamp: March 02, 2022, 10:38:27 pm
content: I need to store some NVM data in a STM32G4 (things like meter kWh counters, flags, etc), and the RTC battery backed up domain looks very attractive with a small lithium cell. It seems nice because:No wear leveling needed like on flashData is small so 128 words of battery backed registers is fineRate of writes is high since no wear limitSo far I've seen the PVD (voltage detect on falling voltage) interrupt used to trigger an ISR that does a FLASH write when power is removed, storing a bunch of stuff that needs to persist across power cycles. I find it can be annoying to implement the wear leveling reliably, and guarantee no data is lost when power is removed during the page erase.I would like to try to use the battery-backed register way since I can write to it at whatever rate needed. How does one handle it if MCU resets exactly when that write happens (BOR, or a debugger/manual reset)? Monitor VCC voltage and don't write when below certain value? Triplicate the data to weed out corrupted word? PVD yet again?

author: thm_w
author_rank: Super Contributor
timestamp: March 02, 2022, 11:00:35 pm
content: Do you have an upstream measurement of the system/battery voltage that you can use to avoid writes when the power is falling?That or use a diode/cap to provide a local reservoir for the MCU, and give yourself lots of time for shutdown.If you are writing 128 words at a time, then I'm sure you could BOR in the middle of that and corrupt the data.If you are writing one word at a time, its SRAM, so I don't think that one word would corrupt.. probably. But you could consider 1 word of ECC, and throw out all of the data if it doesn't match.

author: uer166
author_rank: Super Contributor
timestamp: March 02, 2022, 11:09:56 pm
content: Quote from: thm_w on March 02, 2022, 11:00:35 pmYeah it's one word at a time, or at least all the variables are atomic, so doesn't matter if you end up with one set of new ones and old ones. ECC might be a good solution in case they still get corrupt. Since it's SRAM the exposure is probably a single clock cycle wide, but I don't think anything fundamentally stops a reset exactly coinciding with a SRAM word write, and would only happen once in a blue moon, which is why I want to ensure it doesn't happen by design..

author: thm_w
author_rank: Super Contributor
timestamp: March 02, 2022, 11:20:44 pm
content: Quote from: uer166 on March 02, 2022, 11:09:56 pmAre you giving the user access to a direct reset button to the MCU? Normally that is not accessible, or is wired through other ICs.Debugger reset shouldn't matter, IMO, since you're the one in control of that.

author: uer166
author_rank: Super Contributor
timestamp: March 02, 2022, 11:23:22 pm
content: Quote from: thm_w on March 02, 2022, 11:20:44 pmNah, this user RST/Debug RST/WDG reset are all nice to haves, but may not be a real problem in the real use case. The issue is that even one corruption event disables the whole devices permanently, so a WDG reset not corrupting the counters is a great nice-to-have.

author: thm_w
author_rank: Super Contributor
timestamp: March 02, 2022, 11:28:51 pm
content: Quote from: uer166 on March 02, 2022, 11:23:22 pmDoes G4 have early WDG interrupt? I think most should have that.

author: wek
author_rank: Frequent Contributor
timestamp: March 02, 2022, 11:31:51 pm
content: Are you sure it's 128 *words*? It appears to me to be more like 32 words, i.e. 128 bytes.JW

author: uer166
author_rank: Super Contributor
timestamp: March 02, 2022, 11:49:25 pm
content: Whoops, yes, 32 registers, 1 word each. Still enough!

author: Cerebus
author_rank: Super Contributor
timestamp: March 03, 2022, 04:44:57 am
content: Quote from: uer166 on March 02, 2022, 11:09:56 pmThe STM32G4 has a little fast CRC engine on board. I used it to check/write the last word of the backup RAM with a CRC of the rest of the backup RAM to detect if the RAM content was valid/had been initialised/had got corrupted and wrapped it up with routines for backup RAM read and write so that it got updated automatically on any legitimate writes to backup RAM, and checked on any reads of backup RAM. Pretty trivial to do.

author: uer166
author_rank: Super Contributor
timestamp: March 03, 2022, 03:51:00 pm
content: Quote from: Cerebus on March 03, 2022, 04:44:57 amSure, it is not hard to detect the event, but I need to have a way to recover the data in case there is corruption in the first place, or alternatively make it impossible to corrupt by design. I suppose one could duplicate all data and CRCs, so if one gets rekt the other one (should?) be valid.

author: peter-h
author_rank: Super Contributor
timestamp: March 03, 2022, 09:23:51 pm
content: A rather different way to approach this is this:Use a serial (SPI) FLASH chip like the Adesto '321' or similar. These have two 512 byte buffers, and assuming you have a pre-erased page ready, you can program one or the other buffer into that FLASH page in3ms. So if you can detect a power fail in 3ms, you have a good solution.Setting aside adjacent cell disturbance etc e.g. herehttps://www.eevblog.com/forum/microcontrollers/flash-memory-write-without-pre-erase/msg4033894/#msg4033894you can power down your box 100000 times before that FLASH page wears outIn the meantime you have that 512 byte buffer to use as RAM.I am using the 32F417 and it is difficult to use the RTC RAM for important stuff, because if the box is powered down, the battery/supercap/etc will run down (a 0.22F supercap lasts about 5 days; the 32F4 RTC is hardly a paragon of low Icc; if you want the best you use the 35 years old DS1302 which is about 7x better) and you never know which bits will go first. So you need a CRC or some such...