Managing Configuration Data Across Updates

In this lesson, you will learn how to architect your memory layout to ensure that critical user settings and calibration data persist even when you overwrite your main application code during a firmware update.

When performing In-Application Programming (IAP), the most common mistake is storing configuration data in a memory region that gets erased during the new firmware image download. If your device stores its Wi-Fi credentials or sensor calibration offsets in the same flash sector as your application code, those values will be lost the moment you update your software.

The Partitioning Strategy

To preserve data, you must logically separate your non-volatile memory (NVM) into distinct partitions. A typical layout divides your flash memory into three primary zones:

1. Bootloader: The immutable code responsible for updating the device.
2. Application Slot: The area where your executable firmware lives.
3. Data/Configuration Sector: A dedicated, persistent memory segment that remains untouched during an update.

By using your linker script (the .ld file), you can define a specific memory region for configuration and tell the compiler to place your settings structure there.

// Define a structure to hold your persistent data
typedef struct {
    uint32_t calibration_offset;
    char ssid[32];
    uint32_t crc;
} ConfigData;

// Force this structure into a specific memory section
__attribute__((section(".config_data"))) 
const ConfigData system_config = { 
    .calibration_offset = 125, 
    .ssid = "MyNetwork" 
};

In your linker script, you would map the .config_data section to a memory address range that falls outside the boundaries of your Application Slot.

Ensuring Data Integrity

Because updates can be interrupted or fail, you should treat your configuration partition as a protected zone. When writing updates, always verify that your IAP driver only erases flash blocks assigned to the application area. Furthermore, always include a CRC field within your ConfigData structure. Even if the data survives the update, you must validate the CRC after the reboot to ensure that the memory hasn't been corrupted during power cycling or the update process itself.

Key Takeaway: By defining a dedicated, persistent memory partition via your linker script, you decouple user-specific data from your executable code, ensuring your device's identity and calibration persist across every firmware update.