I2: SO_RCVTIMEO=5s war ein Timeout pro recv(), nicht für die gesamte
Anfrage. Ein Client, der 1 Byte alle 4,9 s schickt, konnte den einzigen
HTTP-Server-Task damit stundenlang belegen (Spec §7.2 will 5 s pro Header).
serve() rechnet jetzt eine absolute Deadline (nl_app_now_ms() + 5000 ms)
und setzt SO_RCVTIMEO vor jedem recv() auf die verbleibende Zeit (mindestens
1 ms); ist die Deadline überschritten, wird die Verbindung sofort verworfen.
Nicht host-testbar (nl_http_server.c bindet SDK-Sockets ein); über den
Firmware-Build verifiziert.
I1: fail_test() kehrte ohne gespeicherte Zugangsdaten stillschweigend nach
AP_ONBOARDING zurück, ohne den Stationsversuch zu trennen; ein danach doch
noch eintreffendes CONNECTED wurde in AP_ONBOARDING ignoriert, aber der
Treiber rief nl_mdns_on_ip_up() unabhängig vom Zustand auf - die Lampe
landete offen im LAN, ohne dass Zugangsdaten gespeichert wurden.
nl_wifi_actions_t bekommt ein neues Feld `disconnect`:
- fail_test() ohne Zugangsdaten setzt es (Timeout/Fehler beendet den
Stationsversuch).
- Ein CONNECTED-Event in AP_ONBOARDING gilt als Ausreißer eines bereits
gescheiterten Versuchs und wird ebenfalls getrennt (Zustand bleibt
unverändert).
- M1: nl_wifi_sm_onboard() trennt jetzt immer vor dem Testverbindungsaufbau,
damit veraltete Events eines vorherigen Versuchs nicht mehr zählen; der
Treiber (nl_wifi_request_onboard) meldet zusätzlich "wifi busy" (503),
solange bereits ein Onboarding-Test läuft.
Der Treiber (src/net/nl_wifi_w600.c) führt `disconnect` vor `connect` aus
und ruft nl_mdns_on_ip_up() nur noch, wenn der Zustand nach der Verarbeitung
tatsächlich STA_CONNECTED ist.
Tests (test_wifi_sm.c): Timeout/Fehler ohne Zugangsdaten -> disconnect;
CONNECTED während AP_ONBOARDING -> disconnect, Zustand unverändert;
erneutes Onboarding während laufendem Test -> disconnect vor dem neuen
connect.
C1: Ein POST an /api/v1/device/state mit tief verschachteltem JSON (z.B.
20 Ebenen "[[[[...") lässt cJSONs rekursiven Parser den 6-KB-Stack des
HTTP-Tasks überlaufen - CJSON_NESTING_LIMIT war mit 1000 viel zu hoch und
FreeRTOS' Stack-Overflow-Checking ist aus. Begrenzt auf 8 Ebenen, sowohl
für die Firmware (third_party/cJSON/cJSON.c) als auch für die
Host-Tests (nl_cjson), damit beide dasselbe Verhalten zeigen.
Test: test_post_validation deckt jetzt einen Body mit 20 verschachtelten
Arrays ab (400 "invalid json").
hardware-checklist.md: Watchdog-Zeile beschreibt jetzt den wdtest-Testablauf (Neustart nach ca. 20-40s), bleibt unabgehakt; neuer Punkt unter "Später (Lampen)" zum SM2135EH-Standby-Bit. README.md: tools/flash.sh full als auf Hardware noch ungetestet markiert.
nl_flash_w600.c: der Header-Kommentar behauptete, tls_spifls_*/tls_fls_* kämen ganz ohne Locking aus - tatsächlich ist nur das Pin-Switching für die >1MB-Region (ioclose/cs/ck-Switching in wm_internal_fls.c) unsynchronisiert, unser Mutex serialisiert ausschließlich ninlights eigene Tasks, nicht SDK-interne Flash-Nutzer wie den Parameter-Store oder fwup (für Plan 2 vorgemerkt). Auch der Kommentar auf nl_flash_region_base() war ungenau. nl_board.c: G95-Kommentar eindeutiger formuliert (aktuelle Tabelle CW=PB13/WW=PB15, alte Lampen ggf. PB16=WW/PB15=CW).
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