ninharp/ninlight-w600
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

fix: printf statt wegkompilierter TLS_DBGPRT_ERR-Meldung bei fls_lock-Fehler

Browse Source 
Wie beim s_fls2_lock-Fehlerpfad (T1, Plan 2) blieb auch ein Fehlschlag beim
Anlegen des primaeren fls_lock-Semaphors unsichtbar, weil TLS_DBGPRT_ERR in
diesem Build wegkompiliert ist. tls_fls_init() haette TLS_FLS_STATUS_ENOMEM
stumm zurueckgegeben. Ergaenzt außerdem den Zeitobergrenzen-Kommentar in
nl_recovery.c: die Obergrenze schuetzt nur gegen einen echten Stillstand,
nicht gegen einen langsamen, aber laufenden Download - wm_fwup.c bedient den
Watchdog bei jeder empfangenen Nachricht selbst.
This commit is contained in:
Michael Sauer
2026-09-12 03:27:13 +02:00
parent f434c013e7
commit 49d6b329b0
2 changed files with 16 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sdk/Platform/Drivers/internalflash/wm_internal_fls.c
+4 -1
View File
@@ -1170,7 +1170,10 @@ int tls_fls_init(void)
if (err != TLS_OS_SUCCESS)
{
tls_mem_free(fls);
TLS_DBGPRT_ERR("create semaphore @fls_lock fail!\n");
/* ninlight patch 5: TLS_DBGPRT_ERR is compiled out in this build, so this failure - the
* whole flash layer stays without its lock and tls_fls_init() returns an error nobody
* prints - would be silent. See sdk/PATCHES.md. */
printf("wm_internal_fls: fls_lock create failed\r\n");
return TLS_FLS_STATUS_ENOMEM;
}
if (tls_os_sem_create(&s_fls2_lock, 1) != TLS_OS_SUCCESS)
src/net/nl_recovery.c
+12 -7
View File
@@ -7,19 +7,24 @@
#include "wm_watchdog.h"
#include "net/nl_wifi.h"
#include "sys/nl_app.h"
#include "sys/nl_ota.h"
#define NL_RECOVERY_SCAN_MS 3000u
#define NL_RECOVERY_JOIN_MS 15000u
#define NL_RECOVERY_BUF 2048u
/* Generous cap on how long the download itself may run. wm_http_fwup.c's own resume loop
can already take up to ~20 minutes on a slow/aborted transfer (200 rounds x up to 5 s
receive timeout / 2 s retry delay), and a real hang - e.g. its unbounded
/* Cap on how long this task keeps feeding the watchdog while the download runs. wm_http_fwup.c's
own resume loop can already take up to ~20 minutes on a slow/aborted transfer (200 rounds x up
to 5 s receive timeout / 2 s retry delay), and a real hang - e.g. its unbounded
"while (!p) { tls_os_time_delay(1); pbuf_alloc(...) }" retry on allocation failure
(wm_http_fwup.c:178) - never returns from t_http_fwup() at all. Past this cap we stop
feeding the watchdog (see below) instead of waiting indefinitely: a watchdog reset is
strictly better than a silent hang with no Wi-Fi and no console, and a fresh boot simply
retries recovery from scratch. */
(wm_http_fwup.c:178) - never returns from t_http_fwup() at all. Past this cap we stop feeding
the watchdog: a watchdog reset is strictly better than a silent hang with no Wi-Fi and no
console, and a fresh boot simply retries recovery from scratch.
I5 (final review), important limitation: this does NOT put a hard time limit on the download.
The SDK's own fwup task calls tls_watchdog_clr() for every message it receives
(sdk/Platform/Common/fwup/wm_fwup.c:201), so a slow but *progressing* transfer keeps the
watchdog alive well past this cap. Only a real stall - the peer stays connected but sends
nothing more, or the allocation loop above spins - actually runs into the reset. */
#define NL_RECOVERY_DOWNLOAD_MAX_MS (10u * 60u * 1000u)
static volatile bool s_scan_done;