hwci: boot the AMYboard with an esptool chip-id reset (fixes the boot-wedge)#1034
Merged
Conversation
…-wedge) The bench intermittently failed with "board MIDI never appeared": after the flash, the board panic-looped in the bootloader (serial log: 0 clean boots, 123 Guru Meditations) and its USB-MIDI never came up. The firmware was fine (same image boots elsewhere; bootloader byte-identical to a booting build) and the board ran fine once the bench let go of it -- the flash's own `--after hard-reset`, with the debug UART held open across boot, left it wedged. The reliable reset (found at the bench): `esptool chip-id` -- it enters download mode, reads the MAC, hard-resets, and *releases the port*; wait ~5s, then the board is up and `amidi -l` finds it. Bake that in: - Flash once, then bring the board up with reset_via_chipid() (verifies the MAC came back), wait --boot-settle (default 5s), then look for MIDI. - Retries do the cheap chip-id reset again, not a 60s re-flash. - Do NOT hold the dongle's DTR/RTS open while booting (that was wedging it); tail the CDC console only after MIDI is up, and grab a debug-UART snapshot only on a real boot failure. Diagnosed with @bwhitman at the physical bench. Verified the loop with mocked reset/wait: all-fail does N chip-id resets (5s settle each) then exits; a boot on attempt 2 resets twice then proceeds.
🔌 AMYboard PR previewEditor + flasher: https://amyboard-pr-1034.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! |
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.
The bug
The AMYboard bench intermittently failed with
[boot] board MIDI never appeared. Pulling the serial log from a failed run: 0 clean boots, 123Guru Meditationpanics across the whole run — after the flash, the board panic-looped in the bootloader and its USB-MIDI never enumerated, so there was nothing to drive.It was not the firmware (same image boots elsewhere; the bootloader is byte-identical to a booting build) and not the board (it runs fine, and
amidi -lshows it, whenever the bench lets go of it). The trigger was the bench's reset path: the flash's own--after hard-reset, with the debug UART held open across boot, left the board wedged in a boot-loop.The fix (found at the bench)
esptool chip-idreliably boots it: it enters download mode, reads the MAC, hard-resets, and releases the port. Wait ~5s and the board is up —amidi -land CDC both work. So:reset_via_chipid()(verifies the MAC actually came back) and wait--boot-settle(default 5s) before looking for MIDI.Testing
py_compileclean. Mocked the loop: all-fail does N chip-id resets (5s settle each) then exits; a boot on attempt 2 resets twice then proceeds. The real bench manual sequence (esptool ... chip-id→ wait 5s →amidi -l) is what this automates.Diagnosed at the physical bench. Supersedes the re-flash retry from #1029 (re-flashing couldn't clear the wedge; a chip-id reset does).
🤖 Generated with Claude Code