Files
ninlight-w600/sdk/PATCHES.md
T
Michael Sauer 4f270ad79b fix: Watchdog wirksam machen, Factory-Reset im App-Task, Resetzähler-Retry
- 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.
2026-09-11 20:53:25 +02:00

2.3 KiB

Ä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.
  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) - das ist unkritisch, da er nur während eines laufenden OTA-Updates feuert und den app_task-Heartbeat in src/app_main.c nicht ersetzt (der Watchdog wird sonst ausschließlich dort über den s_light_beat-Heartbeat des light_task gefüttert). 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.