diff --git a/sdk/Platform/Drivers/internalflash/wm_internal_fls.c b/sdk/Platform/Drivers/internalflash/wm_internal_fls.c
index 8b6f5c8..02837b4 100644
--- a/sdk/Platform/Drivers/internalflash/wm_internal_fls.c
+++ b/sdk/Platform/Drivers/internalflash/wm_internal_fls.c
@@ -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)
diff --git a/src/net/nl_recovery.c b/src/net/nl_recovery.c
index 8117a5a..64a9c4d 100644
--- a/src/net/nl_recovery.c
+++ b/src/net/nl_recovery.c
@@ -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;