AMYBOARD: revert MIDI RX buffer 2048 → 512 (fix boot-loop)#877
Merged
Conversation
Commit 684a04b bumped CFG_TUD_MIDI_RX_BUFSIZE from 512 to 2048 to hold more SysEx chunks for heavy transfer pacing. The resulting v-apr-2026 binary boot-looped on AMYboard hardware with a StoreProhibited panic deep inside ESP-IDF's esp_clk_init() / wdt_hal_write_protect_disable call chain — i.e. BEFORE any tulipcc/amy code runs. The same hardware boots v-mar-2026's image without issue, and rebuilding the apr source with RX_BUFSIZE back at 512 also boots cleanly, so the 2048 value is the proximate cause. Root cause is still unexplained: _midid_itf lives in regular .dram0.bss (not an exotic section), the BSS/heap layout at 2048 still fits in DRAM by a wide margin, and esp_clk_init doesn't touch _midid_itf or any USB state. Theories not yet confirmed: alignment/linker reshuffle moving a symbol into reserved RAM, the TinyUSB FIFO struct hitting an internal limit, or a stack-frame interaction during early init. Filing a follow-up is on the todo list — 512 is empirically safe and matches the pre-commit-684a04bd behavior that worked for months. Per commit 684a04b's rationale: 512 holds ~1.5 sysex chunks of slack. If sysex reliability regresses on slow sketches again we'll need to find a root-cause fix for the 2048 crash rather than just raising the buffer. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Summary
v-apr-2026 AMYBOARD binaries boot-loop with a
StoreProhibitedpanic deep inside ESP-IDF'sesp_clk_init()/wdt_hal_write_protect_disablecall chain — before any tulipcc/amy code runs. Bisect isolates commit 684a04b ("Increase USB MIDI RX buffer to 2048 bytes") as the cause. Reverting justCFG_TUD_MIDI_RX_BUFSIZEfrom2048back to512(the pre-684a04bd value) restores a clean boot on the same hardware.The v-mar-2026 binary was already confirmed to boot fine on the same board, so it's not a hardware regression.
Status
amyboard-full-AMYBOARD.bin,amyboard-firmware-AMYBOARD.bin) have already been overwritten with the fixed build so users can flash right now without waiting for this PR to mergeRoot cause still unknown
_midid_itflives in plain.dram0.bss(not a DMA/RTC/exotic section), BSS+heap at 2048 still fits in DRAM by hundreds of KB, andesp_clk_initdoesn't touch_midid_itfor USB state. Theories not confirmed:tu_fifo_tinternal limit hit at 2048Leaving a follow-up issue on the backlog — 512 is empirically safe and matches the pre-bump behavior that worked for months.
Test plan
idf.py -DMICROPY_BOARD=AMYBOARD build)amyboard-full-AMYBOARD.binon physical AMYboard via web flasher, boots cleanly🤖 Generated with Claude Code