What causes "Multiple stm32xx Cargo features enabled" in embassy-rs/embassy?

Enable exactly one stm32xx chip feature on embassy-stm32 (which propagates to embassy-stm32-wpan) in Cargo.toml

Multiple stm32xx Cargo features enabled

Error message

Multiple stm32xx Cargo features enabled

What it means

embassy-stm32-wpan's build script compiles chip-specific link sections and register definitions, so exactly one stm32xx chip feature must be enabled at compile time. When Cargo's CARGO_FEATURE_STM32* env vars resolve to more than one chip, the build script cannot pick a target and panics with this message during build script execution.

Solutions

Enable exactly one stm32xx chip feature on embassy-stm32 (which propagates to embassy-stm32-wpan) in Cargo.toml
Check `cargo tree -f '{p} {f}'` for what enables extra chip features and remove or gate them
Split projects for different chips into separate packages/workspaces so feature unification cannot merge two chips

Example fix

# before
embassy-stm32-wpan = { version = "0.1", features = ["stm32wb15cc", "stm32wb55xx"] }
# after
embassy-stm32-wpan = { version = "0.1", features = ["stm32wb15cc"] }

Defensive patterns

Strategy: validation

Validate before calling

// build-time: ensure exactly one chip feature; cannot be caught at runtime (build script panic)
// In CI: cargo metadata --format-version 1 | jq to assert single CARGO_FEATURE_STM32 feature
cargo tree -f '{p} {f}' | grep embassy-stm32-wpan

Prevention

Enable exactly one stm32xx chip feature per package
Use a workspace with one package per board/chip
Run cargo tree in CI to detect feature unification of chip features

When it happens

Trigger: Cargo.toml (or a dependency's feature unification) enables two or more features like stm32wb15cc and stm32wb55xx on embassy-stm32-wpan simultaneously.

Common situations: Workspace Cargo.toml turns on multiple chip features via feature unification (e.g. two binaries each requiring a different chip in the same package); copy-pasting examples for different chips into one dependency entry; a third-party crate enabling a second embassy-stm32 chip feature.

Related errors

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

Appendix: source

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

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)