fix: Fix-Runde 2 für Task 4 - Ablehnung sofort statt nach voller Resume-Schleife, Reset-Guard auch bei OOM greifen lassen

This commit is contained in:
Michael Sauer
2026-09-12 02:04:58 +02:00
parent 37c05d2f90
commit 2d5095574d
3 changed files with 36 additions and 1 deletions
+18
View File
@@ -31,6 +31,24 @@ Lib/GNU, Bin/secboot.img, Tools/GNU/link_w600_2m.ld (→ ld/) und wm_tool.c (→
Ü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 ab (Checksummen-
/Trailer-Fehler oder ein anderer fataler fwup-Fehler), 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), deren Daten die fwup-Task
wegen des bereits gesetzten Fehler-Bits (siehe unten) jedes Mal sofort verwarf. `t_http_fwup()` kam
also erst nach Minuten mit dem richtigen Fehler zurück, `s_busy`/`ota_pending` standen so lange.
Springt jetzt direkt nach `QUIT_OTA` (mit `nRetCode = ret`, damit die `socket_fwup_err()`-
Bereinigung am Funktionsende trotzdem läuft) - der Abbruch ist damit sofort sichtbar, nicht erst
nach der vollen Resume-Schleife.
- `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).
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):
+8
View File
@@ -418,6 +418,14 @@ static void fwup_scheduler(void *data)
RSA_SHA256 = tls_mem_alloc(left);
if(!RSA_SHA256)
{
/* ninlight: this used to jump to request_finish without setting any
* error bit. With the C1 fix (see below / sdk/PATCHES.md point 1) the
* request_finish reset only fires when no error bit is set - so this
* was the one remaining way to reach a reset with the trailer never
* actually checked. Report it like the other allocation failure above. */
request->status = TLS_FWUP_REQ_STATUS_FMEM;
fwup->current_state |= TLS_FWUP_STATE_ERROR_MEM;
nl_ota_set_error("download"); /* no more specific value applies */
goto request_finish;
}
while (left > 0)
+10 -1
View File
@@ -181,7 +181,16 @@ int http_fwup(HTTPParameters ClientParams)
// Send received data to fwup thread and deal with socket issues.
s8 ret = socket_fwup_recv(0, p, ERR_OK);
if(ret != ERR_OK){
now_state = SHUTDOWN_LINK;
/* ninlight: socket_fwup_recv() rejected this chunk (the fwup task hit a
* checksum/trailer mismatch or another fatal error, see wm_fwup.c) - recvLen
* never advances past this point, so going through SHUTDOWN_LINK used to start
* a full Range-resume retry (up to NL_OTA_MAX_RETRY_ROUNDS rounds) whose data
* the fwup task would just keep discarding. Bail out to QUIT_OTA directly so
* the caller gets the real error immediately instead of after minutes. Force
* nRetCode nonzero so the socket_fwup_err() cleanup below still runs. See
* sdk/PATCHES.md point 1. */
nRetCode = ret;
now_state = QUIT_OTA;
break;
}
else{