Skip to content

ESP32: Only access PSRAM inside a critical section#230

Open
bugadani wants to merge 1 commit intotaiki-e:mainfrom
bugadani:psram-aware-atomics
Open

ESP32: Only access PSRAM inside a critical section#230
bugadani wants to merge 1 commit intotaiki-e:mainfrom
bugadani:psram-aware-atomics

Conversation

@bugadani
Copy link
Copy Markdown
Contributor

@bugadani bugadani commented Apr 20, 2026

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:

  • It doesn't try to reuse the critical section implementation. This limits changes to existing code considerably, especially it allows not changing the cfg maze. Not making a mess also allows us to make changes like supporting unsafe-assume-single-core easier in the future.
  • The PR replaces core_atomic with a similar-ish implementation for the affected chips.
  • The PR doesn't attempt to rewrite everything in assembly, but instead uses core::sync::atomic. I'm walking back on assembly for the time being to allow progressing on this issue in any (limited) way.
  • If critical-section is 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.

Copilot AI review requested due to automatic review settings April 20, 2026 12:44
@bugadani bugadani changed the title Only access PSRAM inside a critical section ESP32: Only access PSRAM inside a critical section Apr 20, 2026
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.rs to 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.

Comment thread src/imp/xtensa.rs
@bugadani bugadani force-pushed the psram-aware-atomics branch 9 times, most recently from 7a43281 to a4c1561 Compare April 21, 2026 10:02
@bugadani bugadani force-pushed the psram-aware-atomics branch from a4c1561 to bb1c956 Compare April 27, 2026 06:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants