release: ESP32-S3 firmware v0.6.5 — Tmr Svc stack + OTA init refactor#628
Merged
Conversation
… init paths
Three fixes wrapped for the v0.6.5-esp32 release tag:
1. **`sdkconfig.defaults` adds `CONFIG_FREERTOS_TIMER_TASK_STACK_DEPTH=8192`**.
The fix was already in `sdkconfig.defaults.template` (ADR-081, prevents
"stack overflow in task Tmr Svc" bootloop when adaptive_controller emits
feature_state from inside a Timer Svc callback). It was MISSING from the
canonical `sdkconfig.defaults` file used by the build, so any fresh
build picked up the 2 KiB FreeRTOS default and bootlooped on hardware.
Verified on COM7: with the fix, no panics in 30 s of operation; without
it, "***ERROR*** A stack overflow in task Tmr Svc has been detected."
followed by sustained bootloop.
2. **`ota_update.c` extracts `ota_load_psk_from_nvs()` and calls it from
both `ota_update_init()` and `ota_update_init_ex()`.** `main.c:230` uses
the `_ex` variant, but only `ota_update_init()` was loading the PSK
from NVS. Result: `s_ota_psk` stayed empty regardless of NVS contents,
so the RuView#596 fail-closed posture rejected every request — but the
diagnostic warning never printed at boot, leaving operators no signal
about why their OTA uploads were 403'ing. Verified on COM7:
W (3126) ota_update: NVS namespace 'security' not found —
OTA upload endpoint will REJECT all requests until provisioned.
Fail-closed per RuView#596.
3. **`version.txt`: 0.6.4 → 0.6.5**, paired with the v0.6.5-esp32 tag so the
firmware-ci version-guard job (RuView#505 fix-marker) stays happy.
Both validations done end-to-end on hardware (COM7, ESP32-S3 8MB,
provisioned with --edge-tier 2 to also incidentally re-verify #438 is not
reproducible on current main).
Co-Authored-By: claude-flow <ruv@ruv.net>
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
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.
Three real bugs fixed end-to-end on COM7. Required for cutting v0.6.5-esp32.
1. Tmr Svc stack overflow bootloop (sdkconfig.defaults regression)
sdkconfig.defaults.templatehadCONFIG_FREERTOS_TIMER_TASK_STACK_DEPTH=8192(ADR-081 — adaptive_controller emits feature_state from inside Timer Svc callbacks, exceeding the 2 KiB FreeRTOS default). The fix was MISSING fromsdkconfig.defaults(the canonical file the build reads). Result: any fresh build bootlooped:Cherry-picked the same line into
sdkconfig.defaults. Verified on hardware (COM7, ESP32-S3 8MB, edge-tier=2 provisioned): 0 panics, 0 reboots in 30 s.2. OTA PSK never loaded in production code path
main.c:230callsota_update_init_ex(), notota_update_init(). Pre-this-PR, onlyota_update_init()loaded the PSK from NVS. So in production:s_ota_pskstayed empty regardless of NVS contentsExtracted
ota_load_psk_from_nvs()and call it from both init paths. Verified on hardware:3. version.txt bump
0.6.4 → 0.6.5 paired with the v0.6.5-esp32 tag. firmware-ci version-guard job (RuView#505 fix-marker) requires exact match.
Hardware validation matrix
App version: 0.6.5Incidentally closes by hardware-validation
Release artifacts
Six binaries staged in
/tmp/firmware-release-stage/for thegh release create v0.6.5-esp32step:🤖 Generated with claude-flow