Let the 30-pin ESP32 start the radio for an audio recording

[MacNite]

The report

A field report on 0.30.4 had every record_audio command fail on a 30-pin ESP32 hub, while the same firmware and the same hive recorded fine on an ESP32-C6:

[CMD] Received command 66: record_audio
[HEAP] audio-start: free=91296 largest=63476 min_ever=28084
E NimBLEDevice: esp_nimble_hci_init() failed; err=257
[BLE] stack failed to start (no memory for the controller?)
[HI-AUD] BLE stack would not start ... (free heap 16284, largest block 13812)
...
[HEAP] cycle-end: free=71584 largest=34804 min_ever=1456

err=257 is ESP_ERR_NO_MEM. The node was never contacted, so nothing here is HiveInside's.

Two numbers at the end matter more than the failed recording. ~20 kB never came back (91 kB at audio-start, 71 kB at cycle-end with everything torn down), and the cycle's minimum free heap was 1456 bytes — the command-result POST and the OTA check that follow each open a fresh TLS session on that. The failed recording is the harmless half of this.

What changed

The relay asked for the radio last. Three large allocations have to coexist for a recording — the BT controller, the TLS session, and the staging ring — and only the controller can neither shrink to fit nor be retried. It was bidding behind an open TLS session and the 4 kB upload buffer: of the 91 kB at audio-start, 75 kB had gone before it was asked. A new gattaudio::acquireRadio(), split out of begin(), now runs before the TLS connect, so the order is controller → TLS → ring: hardest constraint to softest, and the ring already halves itself down to 8 KiB to fit.

Only the stack moved. The scan and connect stay below the socket. HiveInside disconnects a connection that has not claimed a service within HIVE_LINK_ARM_TIMEOUT_MS (10 s, link.c), and only the START write cancels that timer — hoisting the connect as well would have spent that window on a TLS handshake whose own budget is 15 s, trading an out-of-memory failure for a mysterious disconnect. Connect-to-START is as tight as it always was.

A failed init stranded its memory. NimBLEDevice::init() brings the IDF controller up before it reaches the host, so a host-layer failure returns false with the controller still holding its allocation — and nothing unwound it: NimBLEDevice::deinit() guards on a flag the failed init never set, and blestack::release() early-returns on s_up. acquire() now unwinds it by hand, guarded on esp_bt_controller_get_status(). Deliberately not esp_bt_controller_mem_release(), which would take BLE away for good and leave the next cycle's measurement scan with no radio.

The mic's I2S channel was held all cycle. shutdownMicsI2s() ran only in the deep-sleep prep — which is why [INMP441] I2S uninstalled prints after [SLEEP] in the report. That is 8 kB of DMA-capable internal RAM, the memory the BT controller wants, resident through the TLS handshake and the BLE init, on top of a heap the 2048-point double-precision FFT has just fragmented (91 kB free, but only 63 kB of it in one piece). It is released as soon as the samples are read; the call in storage_power.cpp stays as a no-op.

Why the C6 never showed it

Three of the four differences are build config, not silicon:

• config.h forces ENABLE_INMP441_MICS off on the C6, so it pays for neither the DMA buffers nor the FFT's fragmentation.
• platformio.ini asks esp32dev for 48 NimBLE msys blocks where the C6 takes 24 from its own sdkconfig — and the pool was raised precisely because the classic ESP32 is dual-core and its NimBLE host task competes with the WiFi driver for core 0.
• The C6 has more, less divided DRAM and a BLE-only rather than dual-mode controller.

MSYS1_BLOCK_COUNT is left at 48 on purpose: lowering it would reintroduce the 0.30.2 seams. It is the knob to trade only if the three fixes above turn out not to buy enough headroom.

Verification

Built all three configurations locally with the pinned toolchain. No warnings in any changed file (the only warnings are pre-existing ones in Adafruit's INA219):

Build	Result	Flash
esp32dev (default)	SUCCESS	85.3%
esp32dev with ENABLE_INMP441_MICS=1	SUCCESS	86.9%
xiao_esp32c6	SUCCESS	90.9%

The mic-enabled build is the only one that compiles the sensors.cpp change, since the default config has ENABLE_INMP441_MICS 0.

Not verified: whether a 30-pin hub now completes a recording — that needs the reporter's hardware. On 0.30.6, [HI-AUD] session started in place of BLE stack would not start is the confirmation, and min_ever at cycle-end should no longer collapse toward zero even if the recording still fails for another reason.

Also in this PR

• Firmware version bumped to 0.30.6.
• docs/audio-recording.md: new "Why this is a 30-pin ESP32 problem" section; the "BLE stack would not start" troubleshooting row now points at it.

Update: failure reporting (0.30.8, e85e9db)

Field test of 0.30.7: the TLS error is gone, but the recording now ends as "the hub started uploading but no audio arrived", and the backend logs a ClientDisconnect traceback. Traefik shows the hub closing the upload after 207 ms (499). The BLE session most likely failed to start straight after the socket opened. The hub's single command-result POST then evidently failed as well, so the 5-minute sweep's generic message replaced the real reason.

This commit does not make audio work on the 30-pin board. It makes the failure visible, so the memory fix can be chosen from real numbers:

• Server: stream_recording handles the hub disconnecting early. It stores the bytes that arrived and logs one warning instead of a traceback. A failed command result that arrives after the sweep now replaces the sweep's message (never a /finalize verdict).
• Firmware: the audio result POST is retried once. If the retry also fails, the result is held in RTC memory and delivered on the next cycle (at most 3 tries). A session that fails to start now carries [heap free …, largest …, min …] in its message.
• Tests: added regression checks for the disconnect and for the late result. The server suite and firmware host tests pass, and esp32dev and xiao_esp32c6 build.
• Next: flash 0.30.8 on the 30-pin hub, run a recording, and read the reason and heap numbers from the dashboard.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Jj45DVh6TKdwJ5LyYawqQx

---

Generated by Claude Code