embassy-rs/embassy · error
No mspm0xx/mspsxx Cargo feature enabled
Error message
No mspm0xx/mspsxx Cargo feature enabled
What it means
embassy-mspm0's build script generates chip-specific register/peripheral code based on exactly one enabled chip Cargo feature (e.g. mspm0g350x). When the environment contains no variable starting with CARGO_FEATURE_MSPM0 or CARGO_FEATURE_MSPS, `get_one` returns `GetOneError::None` and the build script panics, failing the build with this message.
Solutions
- Enable exactly one chip feature in Cargo.toml, e.g. `embassy-mspm0 = { version = "...", features = ["mspm0g350x"] }` matching your actual MCU.
- If features are set on a sibling crate, re-export/forward them or enable them directly on embassy-mspm0.
- Check `cargo build -v` / `cargo tree -f '{p} {f}'` that the feature is active in the unit being compiled.
Example fix
// before (Cargo.toml)
embassy-mspm0 = { version = "0.1", default-features = false }
// after
embassy-mspm0 = { version = "0.1", features = ["mspm0g350x"] } Defensive patterns
Strategy: validation
Validate before calling
// Cargo.toml — exactly one chip feature required:
// [dependencies]
// embassy-mspm0 = { version = "0.1", features = ["mspm0g350x"] } Prevention
- Copy the dependency line (with chip feature) from the example matching your board.
- Never set default-features = false without adding a chip feature.
- Verify feature presence with `cargo tree -f '{p} {f}'` after edits.
When it happens
Trigger: Adding `embassy-mspm0` as a dependency with `default-features = false` and no chip feature like `mspm0g350x` enabled; building a workspace where the feature lives on another crate and isn't forwarded.
Common situations: Creating a new project from scratch without copying the chip feature line from an example; upgrading embassy and losing default features; trying to compile the crate standalone (`cargo build` inside the crate dir without features).
Related errors
- Multiple mspm0xx/mspsxx Cargo features enabled
- Multiple time-driver-xxx Cargo features enabled
- unknown time_driver
- Multiple stm32xx Cargo features enabled
- No stm32xx Cargo feature enabled
AI-assisted analysis of embassy-rs/embassy@463a07b963 (2026-09-10).
Data as JSON: /api/errors/7ccc31f438b9b901.
Report an issue: GitHub.
Appendix: source
Thrown at embassy-mspm0/build.rs:42
interrupt_group_linker_magic();
}
fn generate_code(cfgs: &mut CfgSet) {
#[cfg(any(feature = "rt"))]
println!(
"cargo:rustc-link-search={}",
PathBuf::from(env::var_os("OUT_DIR").unwrap()).display(),
);
cfgs.declare_all(&["gpio_pb", "gpio_pc", "int_group1", "unicomm"]);
let chip_name = match env::vars()
.map(|(a, _)| a)
.filter(|x| x.starts_with("CARGO_FEATURE_MSPM0") || x.starts_with("CARGO_FEATURE_MSPS"))
.get_one()
{
Ok(x) => x,
Err(GetOneError::None) => panic!("No mspm0xx/mspsxx Cargo feature enabled"),
Err(GetOneError::Multiple) => panic!("Multiple mspm0xx/mspsxx Cargo features enabled"),
}
.strip_prefix("CARGO_FEATURE_")
.unwrap()
.to_ascii_lowercase()
.replace('_', "-");
eprintln!("chip: {chip_name}");
cfgs.enable_all(&get_chip_cfgs(&chip_name));
for chip in ALL_CHIPS {
cfgs.declare_all(&get_chip_cfgs(&chip));
}
let mut singletons = get_singletons(cfgs);
time_driver(&mut singletons, cfgs);
pin_features(&mut singletons);View on GitHub (pinned to 463a07b963)