ESP32: Only access PSRAM inside a critical section#230
Open
bugadani wants to merge 1 commit intotaiki-e:mainfrom
Open
ESP32: Only access PSRAM inside a critical section#230bugadani wants to merge 1 commit intotaiki-e:mainfrom
bugadani wants to merge 1 commit intotaiki-e:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Routes atomic read-modify-write (RMW) operations on ESP32 / ESP32-S3 to use a critical section when the atomic value resides in PSRAM, avoiding non-atomic behavior of Xtensa CAS on the external data bus.
Changes:
- Add an Xtensa-specific atomic backend (
src/imp/xtensa.rs) that dynamically dispatches RMW operations based on whether the atomic’s address is in PSRAM. - Extend
build.rsto detect ESP32 vs ESP32-S3 on Xtensa targets and set a custom cfg (portable_atomic_target_cpu), and wire module selection via#[path]. - Update CI and docs/changelog to cover the new Xtensa behavior and add an xtensa-esp32s3 no-std build.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| tools/build.sh | Avoid enabling single-core assumption cfgs for xtensa-esp32* targets (comment-only behavior change). |
| src/imp/xtensa.rs | New Xtensa backend that routes PSRAM RMWs through critical-section and uses core atomics otherwise. |
| src/imp/mod.rs | Select Xtensa backend via #[cfg_attr(..., path = "xtensa.rs")]. |
| build.rs | Infer ESP32 vs ESP32-S3 and emit portable_atomic_target_cpu cfg; extend check-cfg allowlist. |
| CHANGELOG.md | Document PSRAM critical-section routing and lock-free status change on ESP32/ESP32-S3. |
| .github/workflows/ci.yml | Add no-std build job for xtensa-esp32s3 target. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
7a43281 to
a4c1561
Compare
a4c1561 to
bb1c956
Compare
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
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.
Second attempt of trying to progress on esp-rs/esp-hal#2027, an alternative approach to #225. This PR has (almost) entirely been generated by Cursor/Claude, with minimal touchups from me after reading through what changes were made. I tried my bst to make sure it's not entirely nonsense, though I don't necessarily understand everything (especially
NotRefUnwindSafe).The key differences from the previous PR are:
cfgmaze. Not making a mess also allows us to make changes like supporting unsafe-assume-single-core easier in the future.core_atomicwith a similar-ish implementation for the affected chips.core::sync::atomic. I'm walking back on assembly for the time being to allow progressing on this issue in any (limited) way.critical-sectionis not enabled, access to PSRAM will panic. Trying to force-require the feature is a weird state to me, although I can flip it into a compile error easily enough if preferred.