tools: add core1 flash-call checker for rp2 USB host builds#11115
Open
mikeysklar wants to merge 2 commits into
Open
tools: add core1 flash-call checker for rp2 USB host builds#11115mikeysklar wants to merge 2 commits into
mikeysklar wants to merge 2 commits into
Conversation
On raspberrypi boards with USB host, core1 runs the PIO-USB frame loop behind an MPU region that makes flash inaccessible, so everything core1 reaches must be RAM-resident. The linker script places the entry points in RAM, but nothing verified their callees — which is how adafruit#10243 happened: an upstream TinyUSB change added a flash-resident call inside RAM-placed tuh_task_event_ready() and core1 died at first device attach. check_core1_flash_calls.py disassembles the linked ELF, walks the static call graph from core1_main (following linker veneers through their literal-pool targets), and fails if any reachable function lives in flash, printing the offending call chain. Run against current builds it catches the adafruit#10243 regression, the Pico-PIO-USB calc_usb_crc16 flash placement (hard-locks the board on any multi-packet OUT transfer, e.g. writing to a USB drive), and a latent flash call chain in the TinyUSB queue mutex contention path. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Jul 14, 2026
Merged
Co-Authored-By: Claude Fable 5 <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.
Follow-up to #10243 / #11114, answering "could we have caught this at build time?" Yes.
On RP2 USB host boards, core1 may only run code that lives in RAM. If it ever steps into flash, it crashes and USB host goes silent. We keep core1's functions in RAM, but nothing ever checked what those functions call. That's how #10243 slipped in.
This script checks the finished firmware: it follows every call core1 can make and fails the build with the guilty call chain if any of them lead into flash. Runs in ~2 seconds using arm-none-eabi-objdump.
Against current builds it catches three real cases:
calc_usb_crc16lives in flash. Verified on hardware: writing to a USB drive hard-locks the board. One-word upstream fix coming in a separate PR.Not wired into CI yet, since 2 and 3 would fail the build until they're fixed.