ESP32: Only access PSRAM inside a critical section

[bugadani]

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]

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.

[bugadani]

@taiki-e is the CI failure somehow my fault? What do I need to do to clear it?

[taiki-e]

Thanks! This looks good overall.

[bugadani]

@taiki-e thank you for your review. I've removed the Atomic64 implementation, cleaned up the rest of your observations, and also added one more commit (also LLM-assisted) that fixes a potential issue with losing stores when they race with an RMW operation.