ninlight-w600/sdk/PATCHES.md

Änderungen am WinnerMicro W600 SDK

Quelle: qcx-w600-firmware/qconnex_sdk/ext/WM_SDK_WM600 (QConnex-Stand 2025). Kopiert wurden nur Include, Platform (ohne Boot/armcc), Src/OS, Src/Network, Src/App/{OTA,httpclient,dhcpserver,dnsserver}, Lib/GNU, Bin/secboot.img, Tools/GNU/link_w600_2m.ld (→ ld/) und wm_tool.c (→ tools/).

1. Platform/Common/fwup/wm_fwup.c: wolfSSL-SHA256 durch nl_sha256_* ersetzt, die QConnex-RSA-Prüfung Check_OTA_Image() durch den Hook nl_fwup_verify_tail() (src/sys/nl_fwup_hook.h). Das Image-Format (Header + Payload + 512-Byte-Endblock) bleibt unverändert. Die starke Definition des Hooks liegt seit Plan 3 in src/sys/nl_ota.c (Trailer-Prüfung über nl_trailer_verify()); die bisherige weak-Variante src/sys/fwup_hook_default.c ist entfallen. Seit Plan 3 bindet wm_fwup.c außerdem sys/nl_ota.h ein (für den nl_fwup_verify_tail()-Hook) — der SDK-Code linkt damit direkt gegen App-Code. Fix-Runde 1 (Task-4-Review) hat drei weitere Stellen in diesem Bereich korrigiert:

   • wm_fwup.c, Bedingung um nl_fwup_verify_tail(): Checksummen- und Trailer-Prüfung liefen in einer kurzschließenden ||-Bedingung; bei falscher Checksumme wurde nl_fwup_verify_tail() nie aufgerufen. Beide Fälle jetzt getrennt behandelt; ein Checksummenfehler ruft nl_ota_set_error("crc") auf, bevor goto request_finish springt (sonst hätte ota_task() ihn als generisches "download" gemeldet).
   • wm_fwup.c, request_finish:-Block: tls_sys_reset() lief unbedingt, sobald der Transfer zu Ende war - auch wenn nl_fwup_verify_tail() oder die Checksummenprüfung das Image gerade abgelehnt hatten. Die Lampe hätte also trotz abgelehntem Image sofort neu gestartet, ota_task() wäre nie zu Ende gelaufen und last_ota_error hätte nie trailer/device_mismatch/hash gemeldet. Der Reset läuft jetzt nur noch, wenn fwup->current_state keinen Fehler-Bit-Satz (TLS_FWUP_STATE_ERROR) trägt.
   • Src/App/OTA/wm_http_fwup.c, HANDLE_BODY: Scheitert tls_fwup_img_header_check(), blieb nRetCode auf HTTP_CLIENT_SUCCESS stehen, wodurch die abschließende if(nRetCode) socket_fwup_err(...)-Bereinigung nie lief und die SDK-eigene fwup-Session (fwup->busy) für jeden weiteren Versuch blockiert blieb. nRetCode wird jetzt in diesem Fall explizit auf HTTP_CLIENT_ERROR_BAD_HEADER gesetzt.
   • Src/App/OTA/wm_http_fwup.c, SHUTDOWN_LINK: Ein abbrechender Download sprang unbegrenzt oft zurück nach PREPARE_PACKET (Resume per Range-Header) - schaltet der Server während der Übertragung ab, hängt t_http_fwup() (und damit der aufrufende Task) für immer. Eine großzügige Obergrenze (NL_OTA_MAX_RETRY_ROUNDS, 200 Resume-Runden) lässt http_fwup() danach mit HTTP_CLIENT_ERROR_SOCKET_TIME_OUT zurückkehren, statt endlos zu warten.

   Fix-Runde 2 (Re-Review von Fix-Runde 1) hat zwei Nachwirkungen der obigen Änderungen behoben:

   • Src/App/OTA/wm_http_fwup.c, HANDLE_BODY: Lehnt socket_fwup_recv() einen Chunk mit ERR_ABRT ab, sprang der Code bisher nach SHUTDOWN_LINK - da recvLen dabei nie den vollen totalLen erreicht, startete das eine komplette Resume-Schleife (bis zu NL_OTA_MAX_RETRY_ROUNDS = 200 Range-Requests). Ursprünglich (Fix-Runde 2) mit der Begründung „die fwup-Task hat abgelehnt" beschrieben - das war zu ungenau: ERR_ABRT bedeutet nicht zwingend eine echte fwup-Ablehnung, siehe die Korrektur in Fix-Runde 3 unten. Springt seit Fix-Runde 3 nur noch bei einer echten Ablehnung direkt nach QUIT_OTA; ein leerer Read (Verbindungsabriss/WLAN-Aussetzer) läuft weiterhin in den Resume.
   • Platform/Common/fwup/wm_fwup.c, Trailer-Puffer-Allokation (RSA_SHA256 = tls_mem_alloc(512)): Schlug das fehl, sprang der Code nach request_finish, ohne ein Fehler-Bit zu setzen. Mit dem Fix-Runde-1-Reset-Guard (siehe oben, !(fwup->current_state & TLS_FWUP_STATE_ERROR)) wäre das der letzte verbliebene Weg gewesen, an nl_fwup_verify_tail() vorbei trotzdem zu resetten - der Trailer wäre dann nie geprüft worden. Setzt jetzt TLS_FWUP_STATE_ERROR_MEM / TLS_FWUP_REQ_STATUS_FMEM (wie die andere Allokationsprüfung in dieser Funktion) und nl_ota_set_error("download") (kein spezifischerer Wert aus dem Vokabular passt hier).

   Fix-Runde 3 (Re-Review von Fix-Runde 2) hat eine echte Regression aus Runde 2 korrigiert:

   • Src/App/OTA/wm_http_fwup.c, HANDLE_BODY: socket_fwup_recv() liefert ERR_ABRT nicht nur bei einer echten fwup-Ablehnung (tls_fwup_request_sync() meldet Checksummen-/Trailer-/Hash-Fehler, oder tls_fwup_enter() lehnt eine noch belegte Session ab), sondern auch für ein leeres Paket: wm_socket_fwup.c macht aus current_pack.datalen == 0 per goto err denselben ERR_ABRT. Ein leeres Paket entsteht regelmäßig ohne jeden fwup-Fehler, wenn HTTPClient.cs HTTPIntrnRecv() (Server schließt mitten im Body, oder recv() liefert wegen eines ECONNRESET/WLAN-Aussetzers 0 Bytes) oder der nSocketEvents < 0-Zweig *nLength = 0 zurückgeben, aber weiterhin HTTP_CLIENT_SUCCESS/HTTP_CLIENT_EOS melden. Der Fix-Runde-2-Fix (QUIT_OTA sofort bei ERR_ABRT) hätte also genau den häufigsten Auslöser des Resume-Mechanismus aus I1 (Runde 1) - einen kurzen WLAN-Aussetzer - fälschlich als endgültigen Abbruch behandelt, obwohl kein Byte falsch geprüft oder geflasht wurde. Fix: Ein nSize == 0-Read wird jetzt schon vor dem pbuf_alloc()/socket_fwup_recv()-Aufruf abgefangen und geht wie vor Runde 2 nach SHUTDOWN_LINK (resumable); socket_fwup_recv() bekommt damit nie mehr ein leeres Paket, sein ERR_ABRT ist ab dann eindeutig eine echte Ablehnung und geht weiterhin sofort nach QUIT_OTA. Diese Unterscheidung über den SDK-eigenen Aufrufer zu treffen ist der direkteste verfügbare Weg - tls_fwup_current_state(session_id) bräuchte die (in wm_socket_fwup.c statische, nicht exportierte) session_id, wäre also ein größerer Eingriff für denselben Effekt. Nebenbei: nRetCode = ret (ein lwIP-err_t in einer sonst HTTP_CLIENT_*-Codes tragenden Variable) durch HTTP_CLIENT_ERROR_BAD_STATE ersetzt.

2. Src/OS/RTOS/include/FreeRTOSConfig.h: configGENERATE_RUN_TIME_STATS 0, QConnex-Debug-Hooks entfernt.

3. undefined reference beim Linken auf EarlyInit und pre_gpio_config (von sdk/Platform/Sys/wm_main.c als extern-Hooks erwartet, aber nur von der App bereitgestellt): minimale Stubs in src/sys/sdk_stubs.c angelegt (leere Funktionskörper). In der alten Firmware (qconnex_sdk/src/qc_main.c) war pre_gpio_config() bereits ein No-Op; EarlyInit() rief dort nur in die QConnex-Hardwareschicht (QCXH_EarlyInit()), die ninlight nicht verwendet. Board-spezifische Frühinitialisierung (falls nötig) folgt in einem späteren Plan.

4. Platform/Sys/wm_main.c: vApplicationIdleHook() hat bisher jedes Mal tls_watchdog_clr() aufgerufen, wenn der Idle-Task lief - also immer dann, wenn kein anderer Task rechenbereit war. Ein Task-Deadlock (z.B. ein Task, der nl_app_lock() hält und nie freigibt) hätte den Watchdog damit nie ausgelöst, weil der Idle-Task munter weiter gefüttert hätte. Der tls_watchdog_clr()- Aufruf wurde entfernt; wfi bleibt. Der einzige verbleibende tls_watchdog_clr()-Aufruf im SDK ist in Platform/Common/fwup/wm_fwup.c (Firmware-Update-Task). Einschätzung aktualisiert (Plan 3, Abschluss-Review): Als dieser Punkt geschrieben wurde, gab es noch keinen OTA-Pfad - das Fenster war rein theoretisch. Inzwischen gilt:

   • Im normalen Betrieb (app_task() in src/app_main.c) füttert nicht mehr jeder Durchlauf den Watchdog, sondern erst, wenn light_task, nl_wifi/nl_mdns und nl_http_server seit dem letzten Füttern alle drei einen eigenen Beat-Zähler erhöht haben - ein einzelner hängender Task (z.B. nl_app_lock() für immer gehalten) lässt den Watchdog jetzt tatsächlich auslaufen. Das war zum Zeitpunkt der ursprünglichen Einschätzung noch nicht gebaut.
   • Solange t_http_fwup() läuft, ruft der SDK-eigene fwup-Task (Platform/Common/fwup/wm_fwup.c:201) bei jeder empfangenen Nachricht selbst tls_watchdog_clr() auf - unabhängig vom Drei-Heartbeat- Gate oben. Das Fenster aus der ursprünglichen Einschätzung besteht also während eines laufenden OTA- oder Recovery-Downloads weiterhin: ein light_task/nl_wifi/nl_http_server-Hänger während dieser Zeit wird vom Watchdog nicht erkannt, weil der fwup-Task ihn unabhängig davon bedient.
   • Für den Recovery-Pfad (src/net/nl_recovery.c, NL_RECOVERY_DOWNLOAD_MAX_MS) gibt es seit Plan 3 zusätzlich eine Obergrenze von 10 Minuten, nach der die Boot-Task selbst aufhört, den Watchdog zu bedienen - das deckt aber nur einen echten Stillstand ab (Gegenstelle bleibt verbunden, sendet aber nichts mehr, oder die pbuf_alloc()-Warteschleife in wm_http_fwup.c hängt), nicht das Fenster oben: ein vorankommender Download hält den Watchdog über wm_fwup.c unabhängig von dieser Obergrenze am Leben. Für den regulären OTA-Pfad (fw_update per REST) gibt es keine entsprechende Obergrenze, da dort ein hängender Download die Lampe im Normalbetrieb belässt statt sie in einen rettungslosen Boot-Zustand zu bringen. Kein Fix in dieser Runde - der Watchdog-Heartbeat müsste dafür wissen, ob der fwup-Task selbst noch vorankommt (z. B. über einen eigenen Beat-Zähler, den app_task zusätzlich zu light/net/http prüft); das ist ein eigenständiger Task für einen späteren Plan. Getestet mit dem Konsolenkommando wdtest (src/sys/nl_console_cmd.c, src/sys/nl_console.c): es hält nl_app_lock() für immer, wodurch light_task und app_task blockieren und der Watchdog den Chip zurücksetzen muss.

5. Platform/Drivers/internalflash/wm_internal_fls.c: Semaphor s_fls2_lock serialisiert den Flash-Pfad oberhalb von 1 MB (Pin-Umschaltung via tls_spifls_cs/ck/di/do_switch war ungeschützt). T1 (Plan 2 final review): tls_fls_init() ignorierte den Rückgabewert von tls_os_sem_create(&s_fls2_lock, 1) stillschweigend - jetzt eine printf()-Meldung (TLS_DBGPRT_ERR ist in diesem Build wegkompiliert), falls das Anlegen fehlschlägt (dann bliebe der Bereich oberhalb von 1 MB unprotokolliert ungeschützt). I5 (Plan 3, Abschluss-Review): Aus demselben Grund (TLS_DBGPRT_ERR wegkompiliert) fehlte auch beim Anlegen von fls_lock (dem primären Flash-Semaphor, wenige Zeilen darüber in tls_fls_init()) jede sichtbare Meldung - ein Fehlschlag hätte tls_fls_init() mit TLS_FLS_STATUS_ENOMEM stumm scheitern lassen. Jetzt ebenfalls ein printf().