Memory retention

AirMobile sensor is going to be switched off abruptly whenever the Peltier cell does not provide enough energy. I need to save application status to resume execution properly after a "black-out"

The MSP430FR MCUs features an internal FRAM to store persistent data in place of the typical Flash. FRAM is a non-volatile memory technology that is uniquely flexible and can be used for program or data memory. It can be written to in a bit-wise fashion and with virtually unlimited write cycles

Variables are allocated in SRAM by the default linker command files. FRAM-based MSP430FR5969 device has 2KB of SRAM. If the variable size is too large to fit in SRAM, the linker command file can be modified or C-language #pragma directives can be used to allocate specific variables or structures in FRAM memory.

The toolchains available for MSP430 all ship with linker command files that define a default memory setup and partitioning, typically allocating program code and constant data into FRAM, and variable data and the system stack to SRAM. In addition, C compiler language extensions are provided that allow you to locate selected variables and data structures into FRAM, allowing you to utilize the benefits of using FRAM for persistent data storage without any further considerations regarding memory partitioning or modifications of the linker command files.

In CCS, there are two C language pragma statements that can be used: #pragma PERSISTENT and #pragma NOINIT. PERSISTENT causes variables to not get initialized by the C startup routine, but rather the debug tool chain initializes them for the first time as the application code is loaded onto the target device. Subsequently, those variables do not get initialized, for example, after a power cycle as they have been completely excluded from the C startup initialization process. Declaring variables as PERSISTENT causes them to get allocated into the .TI.persistent linker memory segment.

Here is a code snippet showing how the variable is declared as persistent:

#pragma PERSISTENT(x)
 unsigned int x = 5;

NOINIT works similar to PERSISTENT but the variables are never initially initialized by the project’s binary image file and the debug tool chain during code download. Declaring variables as NOINIT causes them to get allocated into the .TI.noinit linker memory segment. Note that unlike PERSISTENT, variables declared as NOINIT do not get located in FRAM by the default linker command files, requiring a minor modification of the linker command file if such functionality is required. Here is a corresponding code snippet:

#pragma NOINIT(x)
unsigned int x;

The basic flowchart of the AirMobile firmware is very simple

So I decided to save the application status and the last readings of the 5 sensors

#pragma PERSISTENT(gAppPhase);
int gAppPhase = PHASE_READING_TEMP_RH_NO2;

typedef struct
{
      float temperature;
      float humidity;
      float CO;
      float NO2;
      float dust;
} SENSORS_DATA;
 
#pragma PERSISTENT(SENSORS_Data);
SENSORS_DATA SENSORS_Data;

The application status is saved for obvious reason.

The last readings are saved in order to make a mobile average over the samples