fix(esp32): OTA upload always crashes at esp_ota_end — httpd stack overflow - #1594
Open
jkuscevic wants to merge 1 commit into
Open
fix(esp32): OTA upload always crashes at esp_ota_end — httpd stack overflow#1594jkuscevic wants to merge 1 commit into
jkuscevic wants to merge 1 commit into
Conversation
…mall
esp_ota_end() runs esp_image_verify() on the calling task's stack; the OTA
handler calls it from the httpd task, which uses HTTPD_DEFAULT_CONFIG()'s
4 KB stack. The image-verification path (esp_image + bootloader_mmap) blows
through that deterministically at the end of every upload:
***ERROR*** A stack overflow in task httpd has been detected.
Backtrace: ... vApplicationStackOverflowHook ... bootloader_mmap ...
Observed behavior before the fix (reproduced 5x on two ESP32-S3 Atom S3
Lite nodes, serial-captured): the transfer completes (911,648 bytes in
~73 s), the node panics during esp_ota_end, reboots, and the A/B scheme
boots the old image — so OTA silently never succeeds while looking like a
network error (connection reset) to the client. The /ota auth probes all
pass, which masks the bug until a real upload is attempted.
Fix: config.stack_size = 12288 for the OTA httpd server.
Validated on real silicon (ESP32-S3, CSI streaming at ~40 pps throughout):
same 911,648-byte upload now returns HTTP 200 {"status":"ok"} in 12.8 s,
node reboots into ota_1, and the OTA'd app runs normally.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
OTA upload crashes at validation — httpd task stack too small
Found while hardware-validating #1593 (the #1542 BSSID telemetry PR): our
first real OTA upload to a field node kept failing as a connection reset,
on every attempt, on two different ESP32-S3 Atom S3 Lite nodes.
Mechanism: the
/otahandler callsesp_ota_end()→esp_image_verify()on the httpd task's stack, and
HTTPD_DEFAULT_CONFIG()gives that task 4 KB.The verification path overflows it deterministically at the end of every
upload. Serial capture:
Failure signature (why it hides): the transfer completes (911,648 bytes,
~73 s), the node panics during validation, reboots, and the A/B partition
scheme boots the old image — the client just sees
Recv failure: Connection reset by peer, indistinguishable from a network problem. The/otaauthprobes (403/400) all pass, so the endpoint looks healthy until someone
attempts a real upload. Reproduced 5× across the two nodes.
Fix:
config.stack_size = 12288for the OTA httpd server.Validated on real silicon (node streaming CSI at ~40 pps, edge_tier=2,
throughout): the same 911,648-byte upload now returns
HTTP 200 {"status":"ok"}in 12.8 s, the node reboots intoota_1, and theOTA'd app runs normally (verified streaming + auxiliary packets after boot).