Flash Config

Driver-configurable state (recal triggers, logging/telemetry toggles, slip control mode) is persisted to flash-emulated EEPROM using the NimaLTD ee library (Drivers/Flash_EE/ee.c/.h), which wear-levels a small struct across flash pages so it survives repeated writes without excessive wear on any single sector. The application-level wrapper is Core/Src/App/flash_config.c.

Load, at boot

load_flash_config() is called from main.c, before osKernelInitialize():

1. ee_init(&flash_config, sizeof(flash_config)) sets up the emulation layer for the FlashConfig_t struct.
2. ee_read() pulls the stored bytes in.
3. If flash_config.magic doesn't match FLASH_CONFIG_MAGIC, this is treated as first boot (or a struct layout change): every field is reset to a sensible default and immediately written back with ee_write().
4. The loaded (or defaulted) values are copied into ui_data.button_states_t, which is what the screens actually read from.

Save, on demand

save_flash_config() is called from save_cfgPresenter::saveConfigToFlash(), itself called when the driver confirms on save_cfg_screen. It's the mirror of load: pack the current ui_data.button_states_t into FlashConfig_t, then ee_init() and ee_write(). Saving is explicit and driver-initiated, not automatic on every change, so a bad in-session config doesn't get written until the driver chooses to.

What's actually meaningful to persist

FlashConfig_t stores nine fields: apps_recalibrate, steer_recalibrate, suspension_recalibrate, imu_recalibrate, activate_cooling, sd_logging_on_off, telemetry_on_off, slip_control_on_off, slip_control_mode_enum.

Five of these no longer round-trip meaningfully

apps_recalibrate, steer_recalibrate, suspension_recalibrate, imu_recalibrate, and activate_cooling are recalibration/activation triggers. As of the momentary-button change described in Screens, their ui_data value always settles to 1 after the first tap (the CAN payload always sends 1 on every press; the on-screen toggle feedback is tracked separately, in local UI-only booleans that always start false at boot and are not persisted). These five fields are still saved and loaded, but loading them no longer drives any visible UI state, and saving them no longer captures anything the driver would recognize as "the current setting." The genuinely meaningful persisted fields are sd_logging_on_off, telemetry_on_off, slip_control_on_off, and slip_control_mode_enum.

Interaction with the startup CAN frame

Loading flash config used to also mark ui_data.buttons_updated_flag = 1, causing canTxTask to send the freshly-loaded button state onto the bus the moment the RTOS scheduler started, before the rest of the vehicle network was necessarily up. That immediate send was moved out of flash_config.c and into a 3-second delayed one-shot timer instead; see CAN for why and how.