Skip to content

release: ESP32-S3 firmware v0.6.5 — Tmr Svc stack + OTA init refactor#628

Merged
ruvnet merged 1 commit into
mainfrom
release/v0.6.5-esp32
May 18, 2026
Merged

release: ESP32-S3 firmware v0.6.5 — Tmr Svc stack + OTA init refactor#628
ruvnet merged 1 commit into
mainfrom
release/v0.6.5-esp32

Conversation

@ruvnet
Copy link
Copy Markdown
Owner

@ruvnet ruvnet commented May 18, 2026

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.template had CONFIG_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 from sdkconfig.defaults (the canonical file the build reads). Result: any fresh build bootlooped:

***ERROR*** A stack overflow in task Tmr Svc has been detected.
Backtrace: 0x40375d41:0x3fcbe060 0x4037eac9:0x3fcbe080 …
Rebooting...

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:230 calls ota_update_init_ex(), not ota_update_init(). Pre-this-PR, only ota_update_init() loaded the PSK from NVS. So in production:

Extracted ota_load_psk_from_nvs() and call it from both init paths. Verified on hardware:

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 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

Check Status
8MB binary builds ✅ 1.10 MB, 47% partition free
4MB binary builds ✅ 894 KB, 53% partition free
Flash 8MB to COM7 ✅ Hash verified
Boot at edge-tier=2 (the case #438 reported bootlooping on v0.4.3.1) ✅ Clean boot, edge DSP task started on core 1
30 s steady operation ✅ 0 panics, 0 reboots, 870 log lines, CSI streaming
OTA fail-closed warning ✅ Prints at boot 3.1 s after reset
Embedded version App version: 0.6.5

Incidentally closes by hardware-validation

Release artifacts

Six binaries staged in /tmp/firmware-release-stage/ for the gh release create v0.6.5-esp32 step:

  • bootloader.bin, partition-table.bin, ota_data_initial.bin, esp32-csi-node.bin (8MB)
  • esp32-csi-node-4mb.bin, partition-table-4mb.bin

🤖 Generated with claude-flow

… 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>
@ruvnet ruvnet merged commit f5e2b54 into main May 18, 2026
33 checks passed
@ruvnet ruvnet deleted the release/v0.6.5-esp32 branch May 18, 2026 21:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant