Main Site Documentation

Project - STM32F4 Backup SRAM


#1

STM32F4 Backup SRAM

The core of functionality is contained in two classes, BKPSRAM_RP and BKPSRAM_UP. The former persists “file” information in the backup registers and backup memory, while the latter does not persist the “file” information, leaving it to the user to persist the “file” information across reboots. The former is far more useful, but uses a page size of 128 bytes, one of which is reserved, while the latter uses a page size of 16 bytes, resulting in more efficient storage. A demo program is provided. Here are the class notes:

Backup SRAM, Register Persisted
///
/// This class implements a pseudo-filesystem in the STM32F4 Backup SRAM.
/// RTC Backup Registers 0 - 19 are used for a “page map” leaving none
/// available. There are 3968 bytes of 4k of backup SRAM are available.
///
/// Callers are returned an SRAM_Token object, which contains the amount
/// and register map of the data written. This data is persisted in the
/// backup registers and first 128 bytes of backup memory.
///
/// Note that while it is possible to reset the backup registers without
/// resetting the backup SRAM, doing so clears the page maps, effectively
/// resetting the SRAM managed here to “unused”.
///
/// The Backup SRAM is broken down into 32 128-byte “pages” and as such
/// a write uses a minimum of 128 bytes. The first 1 page is reserved
/// for page map storage.
///
/// Deletes are lazy; the pages are marked as available, but the actual
/// data is not immediately overwritten.
///
/// This class does persist tokens. Storage for 20 tokens is available,
/// and written memory is addressable through these 20 tokens. Look
/// upon these tokens as pre-defined file names.

Backup SRAM, User Persisted
///
/// This class implements a pseudo-filesystem in the STM32F4 Backup SRAM.
/// RTC Backup Registers 12 - 19 are used for a “page map” leaving
/// registers 0 - 11 available. All 4k of backup SRAM is available.
///
/// Callers are returned an SRAM_Token object, which contains the amount
/// and position of the data written. Loss of this token will result
/// in unrecoverable memory usage as well as unrecoverable data.
///
/// Note that while it is possible to reset the backup registers without
/// resetting the backup SRAM, doing so clears the page map, effectively
/// resetting the SRAM managed here to “unused”.
///
/// The Backup SRAM is broken down into 256 16-byte “pages” and as such
/// a write uses a minimum of 16 bytes.
///
/// Deletes are lazy; the pages are marked as available, but the actual
/// data is not immediately overwritten.
///
/// This class does not persist tokens, it is up to the caller to do so
/// on persistent storage if retention of data across reboots is required.
/// Consider this a faster form of storage that costs 288 bytes of slow
/// storage (i.e. SD card) per data set stored.


#2

Very handy! Thanks for sharing!


#3

I propose this for inclusion in the community firmware…


#4

Should the RTC be initialized to enable backup sram ?

BTW I couldn’t find sources for your GMD.STM32F4.Hardware assembly, the ones with the registers and peripherals address space.


#5

Forgive me for losing track of this project. Apparently I uploaded the wrong version somehow. I am uploading a version that does not require any GMD.* assemblies and has some essential code fixes that were missing in the first version. This is all assuming I’ve got my versions straight this time.

My understanding is that the RTC does not have to be initialized, but the clock controller does. But it has been a while since I read the necessary specs…

I’ll be shipping my gerbers off for a prototype run of my next board, and while waiting, I’ll be implementing this code into that project, so I’ll update it if/when I find the bugs.