fix(esp32s3): stop tulip.wifi() crashing with "No free interrupt inputs for AES interrupt"

[bwhitman]

Problem

A TULIP4_R11 user reports tulip.wifi("ssid", "pass") crashes every time with:

No free interrupt inputs for AES interrupt

This is a tulipcc/IDF-config bug — deterministic, reproducible for anyone on this firmware — not a user issue.

Root cause

Wi-Fi's WPA2 handshake triggers a hardware-AES operation. On the ESP32-S3, IDF's default CONFIG_MBEDTLS_AES_USE_INTERRUPT=y makes the AES driver allocate a dedicated interrupt for it (esp_aes_intr_alloc() → esp_intr_alloc(ETS_AES_INTR_SOURCE, …)).

But by the time Wi-Fi starts, tulipcc has already consumed the few free low-priority interrupt slots:

• RGB LCD — GDMA bounce buffers, refreshing continuously (esp32s3_display.c)
• I2S audio (AMY) — continuous DMA
• USB host — ESP_INTR_FLAG_LEVEL1 (usb_host.c:526)
• the Wi-Fi/BT MAC, which grabs several when active(True) runs

So esp_intr_alloc returns ESP_ERR_NOT_FOUND, IDF logs "No free interrupt inputs for AES interrupt", and esp_aes_intr_alloc() then calls abort() — fatal by design. Nothing in tulipcc overrode the default, and this likely surfaced with the ESP-IDF 5.4.1 bump (older IDF busy-waited instead of using an interrupt).

Fix

One line in the shared tulip/esp32s3/boards/sdkconfig.tulip (included by every ESP32-S3 board and AMYboard):

CONFIG_MBEDTLS_AES_USE_INTERRUPT=n

The hardware AES accelerator now busy-waits/polls for completion instead of needing its own interrupt — removing the allocation that was aborting. The only cost is the CPU busy-waiting during long AES ops (TLS); DMA still does the work and audio runs on its own core. This is Espressif's recommended remedy for interrupt exhaustion.

Testing

This PR exercises the exact crash path on real hardware. The AMYboard PR preview workflow rebuilds the TULIP4_R11 firmware with this fix (it triggers on tulip/esp32s3/**), and HW CI then flashes that build onto the physical Tulip and runs tulip_hwci.py --require-wifi, which calls tulip.wifi(...) on-device (tulip_hwci.py:285). Before this fix that step crashes; with it, Wi-Fi should connect and the screenshot upload should pass.

🤖 Generated with Claude Code

[github-actions]

🔌 AMYboard PR preview

Editor + flasher: https://amyboard-pr-1018.vercel.app/editor/

This preview bundles this PR's firmware — its flasher only flashes this build (not the release). Rebuilt on every push; removed when the PR closes.

The hardware CI has been kicked off and should return within a few minutes, stand by!

[github-actions]

🌷 Tulip Web PR preview

Tulip Web: https://tulip-pr-1018.vercel.app/run/

Firmware (this PR build):

• tulip-full-TULIP4_R11.bin — full image, USB-flash at 0x0 with esptool (no Wi‑Fi needed)
• tulip-firmware-TULIP4_R11.bin — app image (OTA partition)
• tulip-sys.bin — filesystem/system partition

On-device OTA: tulip.upgrade(pr=1018) (needs Wi‑Fi).

Rebuilt on every push; removed when the PR closes.

[github-actions]

🎛️ HW CI (physical bench)

AMYboard (USB-MIDI + AMY zP → audio): ✅ PASS — flashed this PR’s firmware; all checks matched the references.

Tulip (TULIP4_R11; serial-REPL audio + WiFi screenshot): ✅ PASS — flashed this PR’s firmware; all checks matched the references.

⬇️ Artifacts: recordings · screenshot · serial logs · run logs

_{Self-hosted bench. Audio spectral-compared to ref/hwci_basic.wav + ref/tulip_basic.wav; Tulip screenshot pixel-compared to ref/tulip_screenshot.png. Both analog outs share one capture card, so the tests run sequentially.}