fix: schema migration forces clean repaint on first err-border-aware boot

Without this, devices upgrading from the old buggy fill-on-error firmware
get stuck on yellow forever: the new code reads NVS_KEY_ERR_BORDER == 0
(default — the old firmware never wrote that key), so the next 304 sees
no err flag and skips the redraw. NVS img_id matches what the server is
serving, so server says "you're current" indefinitely.

Add NVS_KEY_SCHEMA_V. On boot, if stored version is below
NVS_SCHEMA_VERSION (currently 1), treat errBorder as set for this cycle
and bump schema_v. The next 304 then redraws from LittleFS (the cached
.bin survives flashing) and clears the flag.

Tests: FW-06f locks in the upgrade path (schema_v missing → redraw on
304). FW-06g asserts the migration is one-shot (post-bump → no redraw
on steady-state 304). FW-06d updated to set schema_v explicitly so it
represents the post-migration steady state.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-06 13:36:00 -04:00
parent 5f8f10ed5b
commit db50ce1d0a
3 changed files with 57 additions and 2 deletions
+5
View File
@@ -31,6 +31,11 @@
#define NVS_KEY_IMG_ID "img_id"
#define NVS_KEY_DRAW_NEEDED "draw"
#define NVS_KEY_ERR_BORDER "err" // set when display is showing a sync-fail border; force a clean redraw on next 200/304
#define NVS_KEY_SCHEMA_V "schema_v"
// Bump when introducing a schema migration. Each new value can force a one-shot
// recovery action on first boot of the new firmware.
#define NVS_SCHEMA_VERSION 1
// Width of the sync-fail / no-WiFi border, in pixels.
#define BORDER_THICKNESS_PX 16
+14
View File
@@ -67,8 +67,22 @@ void normal_operation_impl(const String& mac, HTTP& http, const String& url, Pre
int32_t currentImgId = prefs.getInt(NVS_KEY_IMG_ID, -1);
bool drawNeeded = prefs.getInt(NVS_KEY_DRAW_NEEDED, 0) != 0;
bool errBorder = prefs.getInt(NVS_KEY_ERR_BORDER, 0) != 0;
int schemaV = prefs.getInt(NVS_KEY_SCHEMA_V, 0);
prefs.end();
// Schema migration: on first boot under err-border-aware firmware, the
// display may be holding a stale full-screen yellow from the old buggy
// epd_fill(YELLOW) path. The old firmware never wrote NVS_KEY_ERR_BORDER,
// so we'd have no other signal that a clean repaint is needed. Force one
// by treating this boot as if errBorder were set, then bump schema_v so
// it doesn't fire again.
if (schemaV < NVS_SCHEMA_VERSION) {
errBorder = true;
prefs.begin(NVS_NAMESPACE, false);
prefs.putInt(NVS_KEY_SCHEMA_V, NVS_SCHEMA_VERSION);
prefs.end();
}
if (currentImgId >= 0) {
http.addHeader("X-Current-Image-Id", String(currentImgId));
}