embassy-rs/embassy · error

No stm32xx Cargo feature enabled

Error message

No stm32xx Cargo feature enabled

What it means

embassy-stm32-wpan's build script requires exactly one `stm32xx` Cargo feature (the chip selection) to know which STM32 wireless MCU register definitions to generate. If no CARGO_FEATURE_STM32* variable is present at build time, no chip was selected, and the build script panics before compiling the crate.

Solutions

  1. Enable exactly one chip feature in Cargo.toml, e.g. `embassy-stm32-wpan = { version = "...", features = ["stm32wb55xx"] }`
  2. If you intentionally disabled default features, add your target chip feature explicitly
  3. Verify with `cargo tree -f '{f}'` or `cargo metadata` that the stm32 feature reaches embassy-stm32-wpan in your workspace (a feature unification issue may drop it)
  4. Enable `embassy-stm32-wpam/unstable` only together with a chip feature as documented in the crate README

Example fix

// before (Cargo.toml)
embassy-stm32-wpan = { version = "0.1", default-features = false }
// after
embassy-stm32-wpan = { version = "0.1", features = ["stm32wb55xx"] }
Defensive patterns

Strategy: validation

Validate before calling

// verify feature selection before building (shell)
cargo metadata --format-version 1 | \
  jq -e '.packages[] | select(.name=="embassy-stm32-wpan") | .features | keys | any(test("^stm32"))'

Try / catch

// build-script panic happens before your code runs; fix Cargo.toml features
[dependencies]
embassy-stm32-wpan = { version = "0.1", features = ["stm32wb55xx"] }

Prevention

When it happens

Trigger: Building embassy-stm32-wpan as a dependency without enabling a chip feature like `stm32wb55xx` or `stm32wl55xx` in its [features] configuration; running `cargo check` in the crate with no default feature selected; forgetting the feature in a workspace member's dependency declaration.

Common situations: Adding embassy-stm32-wpan to Cargo.toml with default-features = false and no chip feature; copying a dependency line without features; tooling/builds that strip features; enabling two conflicting chip features would instead hit the companion 'Multiple' panic.

Understand the failure class

Background: "X is required", "must be set", "cannot be empty": the missing-required-config error family, from Vertex AI project/location to WeChat keys — this error's family across 18 libraries.

Related errors

AI-assisted analysis of embassy-rs/embassy@463a07b963 (2026-09-10). Data as JSON: /api/errors/1dbbb96e1a5f5781. Report an issue: GitHub.

Appendix: source

Thrown at embassy-stm32-wpan/build.rs:11

use std::path::PathBuf;
use std::{env, fs};

fn main() {
    match env::vars()
        .map(|(a, _)| a)
        .filter(|x| x.starts_with("CARGO_FEATURE_STM32"))
        .get_one()
    {
        Ok(_) => {}
        Err(GetOneError::None) => panic!("No stm32xx Cargo feature enabled"),
        Err(GetOneError::Multiple) => panic!("Multiple stm32xx Cargo features enabled"),
    }

    let out_dir = &PathBuf::from(env::var_os("OUT_DIR").unwrap());

    // ========
    // stm32wb tl_mbox link sections

    let out_file = out_dir.join("tl_mbox.x").to_string_lossy().to_string();
    let in_file;
    if env::var_os("CARGO_FEATURE_EXTENDED").is_some() {
        if env::vars()
            .map(|(a, _)| a)
            .any(|x| x.starts_with("CARGO_FEATURE_STM32WB1"))
        {
            in_file = "tl_mbox_extended_wb1.x.in";
        } else {
            in_file = "tl_mbox_extended_wbx5.x.in";

View on GitHub (pinned to 463a07b963)