Schlägt die Mutex-Erstellung für s_lock fehl, wird jetzt "FATAL: cannot create app lock" ausgegeben und UserMain kehrt zurück, statt mit einem NULL-Mutex weiterzumachen und den App-Task zu starten.
- vApplicationIdleHook() füttert den Watchdog nicht mehr (sdk/Platform/Sys/wm_main.c,
dokumentiert als Patch 4 in sdk/PATCHES.md). Bisher fütterte der Idle-Task den
Watchdog bei jedem Leerlauf, auch wenn ein Task deadlockt (z.B. nl_app_lock() hält
und nie freigibt) - der Watchdog konnte so nie greifen.
- Neues Konsolenkommando `wdtest` (Parser in nl_console_cmd.c/.h, Ausführung in
nl_console.c, Host-Test in test_console_cmd.c): hält nl_app_lock() für immer, damit
light_task und app_task blockieren und nur der Watchdog-Reset den Chip retten kann.
- nl_app_request_factory_reset() (nl_app.h) setzt nur ein volatile Flag; app_task
prüft es in der Hauptschleife und ruft nl_app_factory_reset() selbst auf, da nur der
App-Task die Flash-Stores besitzt. Das Konsolenkommando `factory` ruft jetzt diese
Funktion statt nl_app_factory_reset() direkt aufzurufen, um die Race mit
nl_state_log_append()/nl_resetcnt_clear() im App-Task zu vermeiden. Der Bootpfad
(Bootzähler >= 5) ruft weiterhin direkt nl_app_factory_reset() auf.
- nl_resetcnt_clear() wird nur noch als erledigt markiert, wenn es 0 zurückgibt, damit
ein fehlgeschlagener Clear in der nächsten Schleifeniteration erneut versucht wird.
nl_led_init(board) läuft jetzt direkt nach nl_flash_init(), noch vor dem Reset-Counter/Settings/State-Log-Scan, damit die LEDs von Anfang an dunkel bleiben statt erst nach dem Flash-Scan initialisiert zu werden.
Implementiert:
- Flash HAL (nl_flash_read/write/erase_sector) Interfaces
- Flash Layout mit A/B-Settings Slots und weiteren Regions
- Test-Fake für Flash mit Fehlerinjection (Stromausfall-Simulation)
- Settings-Store mit CRC32 Recovery und Slot-Alternierung
- Vollständige Test-Suite mit Corruption/Power-Loss-Tests
Michael Sauer