Support for ESP32-C3

[makepaddev]

Hi,

I'm trying to compile esp-wifi 0.3.0 which depends on portable-atomic (since 0.2.0). However portable atomic doesn't want to compile:
The CPU is the ESP32-C3 (32 bit RiscV afaik)

error: cfg(portable_atomic_unsafe_assume_single_core) does not compatible with this target;
if you need cfg(portable_atomic_unsafe_assume_single_core) support for this target,
please submit an issue at https://github.com/taiki-e/portable-atomic
--> /Users/admin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.6.0/src/lib.rs:362:1
|
362 | / compile_error!(
363 | | "cfg(portable_atomic_unsafe_assume_single_core) does not compatible with this target;\n
364 | | if you need cfg(portable_atomic_unsafe_assume_single_core) support for this target,\n
365 | | please submit an issue at https://github.com/taiki-e/portable-atomic"
366 | | );
| |_^

Issue in esp-wifi:
esp-rs/esp-wifi-sys#426

[taiki-e]

Currently, unsafe_assume_single_core cannot be enabled on targets that support atomic CAS.

I would expect to get this error if the v2 resolver is not enabled or if there are dependencies that have this feature enabled by mistake.

(We can loosen this check as it will be ignored even if you enable that feature, but I believe that if you get this error, it indicates that the dependency or build configuration may be incorrect.)

Could you tell me specifically how to reproduce this problem?

[makepaddev]

I have uploaded my current little project here: https://github.com/makepaddev/rc_radio
You need this:
rustup toolchain install nightly --component rust-src
rustup target add riscv32imc-unknown-none-elf

then you should be able to call cargo build to see the errors

[taiki-e]

Thanks.

CAS is enabled in your configuration, and the esp32c3 feature of the esp-hal enables unsafe_assume_single_core.

One way around the error here is to stop enabling CAS in the configuration. Like esp-rs/esp-wifi-sys#337 (comment).

Related: esp-rs/riscv-atomic-emulation-trap#11

[makepaddev]

If i comment out the CAS flags in my configuration it gives the exact same compiler error
error: cfg(portable_atomic_unsafe_assume_single_core) does not compatible with this target;
if you need cfg(portable_atomic_unsafe_assume_single_core) support for this target,
please submit an issue at https://github.com/taiki-e/portable-atomic
--> /Users/admin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/portable-atomic-1.6.0/src/lib.rs:362:1
|
362 | / compile_error!(
363 | | "cfg(portable_atomic_unsafe_assume_single_core) does not compatible with this target;\n
364 | | if you need cfg(portable_atomic_unsafe_assume_single_core) support for this target,\n
365 | | please submit an issue at https://github.com/taiki-e/portable-atomic"
366 | | );
| |_^

[taiki-e]

I cloned the reproduction and built it, but it seems that the line that enables the a feature also needs to be removed.

error: failed to run custom build command for `esp-hal-common v0.15.0`

Caused by:
  process didn't exit successfully: `/Users/taiki/projects/tmp/rc_radio/target/debug/build/esp-hal-common-6d7c78c82ede23cb/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at /Users/taiki/.cargo/registry/src/index.crates.io-6f17d22bba15001f/esp-hal-common-0.15.0/build.rs:155:9:
  Atomic emulation flags detected in `.cargo/config.toml`, this is no longer supported!
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/ba7c7a301984967c8c13adb580ef9b86ba706a83/library/std/src/panicking.rs:645:5
     1: core::panicking::panic_fmt
               at /rustc/ba7c7a301984967c8c13adb580ef9b86ba706a83/library/core/src/panicking.rs:72:14
     2: build_script_build::main
               at ./build.rs:155:9
     3: core::ops::function::FnOnce::call_once
               at /rustc/ba7c7a301984967c8c13adb580ef9b86ba706a83/library/core/src/ops/function.rs:250:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...

And, at least the following changes appear to have fixed the error from portable-atomic.

diff --git a/.cargo/config.toml b/.cargo/config.toml
index c23f0e2..ac3dcba 100644
--- a/.cargo/config.toml
+++ b/.cargo/config.toml
@@ -12,7 +12,7 @@ rustflags = [
 
   # comment the cfgs below if you do _not_ wish to emulate atomics.
   # enable the atomic codegen option for RISCV
-  "-C", "target-feature=+a",
+#  "-C", "target-feature=+a",
   # tell the core library have atomics even though it's not specified in the target definition
   "--cfg", "target_has_atomic_load_store",
   "--cfg", 'target_has_atomic_load_store="8"',
@@ -20,11 +20,11 @@ rustflags = [
   "--cfg", 'target_has_atomic_load_store="32"',
   "--cfg", 'target_has_atomic_load_store="ptr"',
   # enable cas
-  "--cfg", "target_has_atomic",
-  "--cfg", 'target_has_atomic="8"',
-  "--cfg", 'target_has_atomic="16"',
-  "--cfg", 'target_has_atomic="32"',
-  "--cfg", 'target_has_atomic="ptr"',
+#  "--cfg", "target_has_atomic",
+#  "--cfg", 'target_has_atomic="8"',
+#  "--cfg", 'target_has_atomic="16"',
+#  "--cfg", 'target_has_atomic="32"',
+#  "--cfg", 'target_has_atomic="ptr"',
 ]

---

If i comment out the CAS flags in my configuration it gives the exact same compiler error

I think you may encountered a cargo problem where the rustflags change in config does not trigger a rebuild, try cleaning build artifacts by cargo clean.

[makepaddev]

Ah yea that fixed it, the atomic thing. Now i get an error with 'interrupt not found' but thats not your problem. Ok thanks!

[clarkmcc]

@taiki-e I've been hitting this error for the last few days now and can't seem to get around it. I tried your suggestion of enabling the a flag and I also through on the cfg flags for emulating atomics, but still getting the error. I'm wondering now if something in the ecosystem has changed this this issue popped up earlier this year. Any ideas? I'll attach the basically empty Rust project that reproduces the error.

cfg(portable_atomic_unsafe_assume_single_core) does not compatible with this target;
       if you need cfg(portable_atomic_unsafe_assume_single_core) support for this target,
       please submit an issue at <https://github.com/taiki-e/portable-atomic>

[build]
target = "riscv32imc-esp-espidf"

[target.riscv32imc-esp-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor" # Select this runner for espflash v3.x.x
rustflags = [
    "-C", "target-feature=+a",
    "--cfg",  "espidf_time64",
    # Enable atomic emulation
    "--cfg", "target_has_atomic_load_store",
    "--cfg", 'target_has_atomic_load_store="8"',
    "--cfg", 'target_has_atomic_load_store="32"',
    "--cfg", 'target_has_atomic_load_store="ptr"',
] # Extending time_t for ESP IDF 5: https://github.com/esp-rs/rust/issues/110

[unstable]
build-std = ["std", "panic_abort"]

[env]
MCU="esp32c3"
# Note: this variable is not used by the pio builder (`cargo build --features pio`)
ESP_IDF_VERSION = "v5.2.2"

# Workaround for https://github.com/esp-rs/esp-idf-template/issues/174

CRATE_CC_NO_DEFAULTS = "1"

Archive.zip

[taiki-e]

@clarkmcc
riscv32imc-esp-espidf already has atomics. You don't need to set portable_atomic_unsafe_assume_single_core. IIUC, setting target-feature=+a and target_has_atomic_* manually is also wrong for that target.

$ rustc --print cfg --target riscv32imc-esp-espidf | grep atomic
target_has_atomic
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_equal_alignment="16"
target_has_atomic_equal_alignment="32"
target_has_atomic_equal_alignment="8"
target_has_atomic_equal_alignment="ptr"
target_has_atomic_load_store
target_has_atomic_load_store="16"
target_has_atomic_load_store="32"
target_has_atomic_load_store="8"
target_has_atomic_load_store="ptr"

[clarkmcc]

@taiki-e. Thanks for the quick response!

You don't need to set portable_atomic_unsafe_assume_single_core

Yeah but if I just stick with the default config.toml I still get the same error, which is what led me to these suggestions originally.

[build]
target = "riscv32imc-esp-espidf"

[target.riscv32imc-esp-espidf]
linker = "ldproxy"
runner = "espflash flash --monitor" # Select this runner for espflash v3.x.x
rustflags = [
    "--cfg",  "espidf_time64",
] # Extending time_t for ESP IDF 5: https://github.com/esp-rs/rust/issues/110

[unstable]
build-std = ["std", "panic_abort"]

[env]
MCU="esp32c3"
# Note: this variable is not used by the pio builder (`cargo build --features pio`)
ESP_IDF_VERSION = "v5.2.2"

# Workaround for https://github.com/esp-rs/esp-idf-template/issues/174
CRATE_CC_NO_DEFAULTS = "1"

[taiki-e]

@clarkmcc
What does your Cargo.toml look like? (I never download random zips due to security risks)

I think it is most likely either your crate's dependency has unsafe_assume_single_core incorrectly enabled, or you have incorrectly enabled the feature that enables it, or you are using an older cargo feature resolver and are therefore affected by the cargo bug.

[clarkmcc]

@taiki-e ah no worries, that's fair

[package]
name = "esp32-c3"
version = "0.1.0"
edition = "2021"

[dependencies]
# Embassy
embassy-executor = { version = "0.6", default-features = false, features = ["task-arena-size-81920"] }
embassy-sync = { version = "0.6", default-features = false }
embassy-time = { version = "0.3", default-features = false, features = ["generic-queue"]}
embassy-net = { version = "0.4", default-features = false , features = ["dhcpv4", "dns", "tcp", "udp"] }

# Hardware Abstraction Layer
embedded-hal = { version = "1", default-features = false }
embedded-hal-async = { version = "1", default-features = false }
embedded-hal-bus = { version = "0.1", default-features = false, features = ["async"] }
embedded-io-async = { version = "0.6", default-features = false }

# ESP specifics
esp-hal = { version = "0.20", default-features = false, features = ["esp32c3", "async"] }
esp-hal-embassy = { version = "0.3", default-features = false, features = ["executors"] }
esp-backtrace = { version = "0.14", default-features = false, features = ["esp32c3", "panic-handler", "exception-handler", "println"] }
esp-println = { version = "0.11", default-features = false, features = ["esp32c3", "log", "uart", "colors"] }
#esp-wifi = { version = "0.9", default-features = false, features = ["esp32c3", "wifi", "async", "tcp", "ipv4", "dhcpv4", "embassy-net"] }

# Logging
log = { version = "0.4", default-features = false }

[taiki-e]

That error occurs because the esp32c3 feature of esp-hal enables unsafe_assume_single_core.

However, IIUC, esp-hal (and other esp-hal-related crates) are crates for no-std targets (*-none-elf), not for ESP-IDF (*-esp-espidf). ESP-IDF can use std, so these crates should not be needed.

Perhaps you need to make sure that the target you are actually trying to compile matches the target used in the example or template you are referring to.