Safety Backup RAM¶
Overview¶
The STM controller’s backup RAM is used to store different kinds of information that shall be preserved if the controller resets. The hardware setup is missing a separate powersupply for the controller’s backup domain. Therefore, the backup RAM is cleared, when the power is cut.
The backup RAM is used to store permanent error flags (See Safety Flags). This ensures the flags that trigger hard faults / the panic mode, can be identified, although the wathcoog resets the controller. The only way to clear them is by cutting the power. Because cutting the power is a way to clear the backup RAM, no separate method for clearing the error entries in the backup RAM is defined.
The backup RAM contents are protected by a CRC Checksum.
The backup RAM is initialized and checked after boot. If the controller starts from a powered down state, the backup RAM is empty. This is detected by an invalid Header at the beginning of the backup RAM. If this is the case, the safety ocntoller will create a valid backup RAM image with a Header, empty Boot Status Flag Entries, empty Config Overrides, an empty Error Memory, and a valid CRC Checksum.
If the Header is valid during boot (verified by plausible values and correct magic numbers), the backup RAM is CRC checked and the error memory is checked for valid entries. In case of a CRC error or invalid entries in the error memory, the Backup RAM is wiped and reinitialized. On top of that, the error flag ERR_FLAG_SAFETY_MEM_CORRUPT is set.
Note
It may be possible that future versions of the hardware include a backup RAM battery / Goldcap. In this case, a way to clear the error memory will be implemented, because it will no longer be possible to clear the error memory by cutting the power. On top of that, the backup memory will also contain the calibration data.
Note
The firmware will not use the NOP entries of the error memory by default, but they will be respected by the validity checker.
Partitioning and Entries¶
The backup RAM consists of multiple sections. The memory section are listed below.
Header¶
The backup memory header is located at offset address:
-
SAFETY_MEMORY_HEADER_ADDRESS0UL¶ Offset address for the safety_memory_header.
- Note
Any other value than 0UL doesn’t really make sense. Therfore, this should not be changed.
The header is defined by the following structure:
-
struct
safety_memory_header¶ Safety memory header.
Public Members
-
uint32_t
magic¶ Magic. Set to SAFETY_MEMORY_MAGIC.
-
uint32_t
boot_status_offset¶ Offset of the safety_memory_boot_status struct (in 32 bit words)
-
uint32_t
config_overrides_offset¶ Offset address of override entries.
-
uint32_t
config_overrides_len¶ Length of override entries in words.
-
uint32_t
firmware_update_filename¶ Filename of the firmware update. This string is at maximum 256 bytes long including the 0 terminator.
-
uint32_t
err_memory_offset¶ Offset of the error memory.
-
uint32_t
err_memory_end¶ End of the error memory. This points to the word after the error memory, containing the CRC of the whole backup RAM.
-
uint32_t
crc¶ CRC of the header.
-
uint32_t
The validity of the header is checked, if the magic and inverse amgic fields contain the correct values, and if the offset address pointers
have values that are located inside the error memory and are not 0 or the same value.
The safety memory header magic is:
-
SAFETY_MEMORY_MAGIC0x12AA5CB7¶ Magic number to signal a valid safety memory header.
Boot Status Flag Entries¶
The boot status flag entries are use to store system states over resets. The flags are stored in memory using the follwoing structure:
-
struct
safety_memory_boot_status¶ Public Members
-
uint32_t
reboot_to_bootloader¶ Reboot into the bootloader.
When this flag is set, the controller will load the bootloader to memory and execute it.
-
uint32_t
code_updated¶ Bootloader has updated the code.
This flag is set, if the firmware ahs been updated successfully
-
uint32_t
reset_from_panic¶ reset_from_panic
This flag is set, when entering the panic mode. Because the panic mode is reset by a watchdog reset, this flag is needed, in order to ensure, that the panic is handled correcly after the watchdog reset.
-
uint32_t
Flags are evaluated active, if the corresponding word is unequal to 0.
Config Overrides¶
Config overrides are used to override persistance and flag weights dynamically. The safety controller will parse the entries on startup.
Entry |
Byte 1 (LSB) |
Byte 2 |
Byte 3 |
Byte 4 (MSB) |
|---|---|---|---|---|
Weight override |
|
|
|
reserved don’t care (written as 0xAA) |
Persistance override |
|
|
|
reserved don’t care (written as 0xBB) |
All words, not matching the table above are ignored and do not cause an error. By default the firmware fills this memory area with zeroes.
Error Memory¶
The error memory contains error entries in form of 32 bit words. The entries are coded as stated below.
Error Flag entries are used to restore error flags after boot. In theory, all flags can be set using this entry type.
However, only persistent flags are stored in the error memory by the firmware.
NOP entries have no meaning. They are used as a filler. When adding a new error memory entry, the error memory is scanned until the first NOP entry is found.
It is replaced with a valid entry. If the error memory contains a word, that is not defined below, it is considered invalid and will trigger the RAM checker on boot.
NOP entries can be used to preallocate the error memory in advance. if the end of the error memory is reached, it is expanded by 1 word to first
the new error entry, until the backup RAM is full. After this, no further errors are stored.
If the same persistent error is triggered mutliple times, the COUNTER in the error entry is incremented.
Entry |
Byte 1 (LSB) |
Byte 2 |
Byte 3 |
Byte 4 (MSB) |
|---|---|---|---|---|
Error Flag |
|
|
|
|
NOP Entry |
|
|
|
|
CRC Checksum¶
The CRC checksum is located after the error memory. The checksum is calculated by the internal peripheral module of the STM32F4 controller. Therefore, the CRC calculation is fixed.
The polynomial is 0x4C11DB7 (Ethernet CRC32):