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

Keep exactly one chip feature enabled in your Cargo.toml and remove the others.

Multiple mimxrt/lpc Cargo features enabled

Error message

Multiple mimxrt/lpc Cargo features enabled

What it means

Companion to the 'No mimxrt/lpc Cargo feature enabled' check: the build script requires exactly one chip-family feature. If Cargo's environment exposes more than one `CARGO_FEATURE_MIMXRT*` or `CARGO_FEATURE_LPC*` variable, the chip target is ambiguous, so generation cannot proceed and the script panics.

Solutions

Keep exactly one chip feature enabled in your Cargo.toml and remove the others.
If a dependency enables a conflicting chip feature, vendor/patch that crate or align the whole workspace on the same single chip feature.
Use per-target Cargo.toml configurations (`[target.'cfg(...)'.dependencies]`) if building for multiple boards from one workspace.

Example fix

// before
embassy-nxp = { version = "0.1", features = ["mimxrt1062", "lpc55s69"] }
// after
embassy-nxp = { version = "0.1", features = ["mimxrt1062"] }

Defensive patterns

Strategy: validation

Validate before calling

# Count enabled NXP chip features in Cargo.toml:
let features: Vec<_> = std::env::vars().map(|(a, _)| a).filter(|a| a.starts_with("CARGO_FEATURE_MIMXRT") || a.starts_with("CARGO_FEATURE_LPC")).collect();
assert_eq!(features.len(), 1, "exactly one NXP chip feature required: {:?}", features);

Prevention

Keep one canonical chip-feature declaration in the workspace root and reference it elsewhere.
Audit dependency feature unification with `cargo tree -e features` when multiple boards share a workspace.
Never enable two chip features 'to test' — build separate targets instead.

When it happens

Trigger: Cargo.toml lists two or more chip features at once, e.g. `features = ["mimxrt1062", "lpc55s69"]`, or two crates in the dependency graph each enable a different chip feature for the same embassy-nxp instance.

Common situations: Workspace members enabling different NXP chip features that unify; copying feature lists from multiple board examples; enabling both an mimxrt and an lpc feature to 'try both'.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors

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

Appendix: source

Thrown at embassy-nxp/build.rs:30

use quote::format_ident;
#[allow(unused)]
use quote::quote;

#[path = "./build_common.rs"]
mod common;

fn main() {
    let mut cfgs = common::CfgSet::new();
    common::set_target_cfgs(&mut cfgs);

    let chip_name = match env::vars()
        .map(|(a, _)| a)
        .filter(|x| x.starts_with("CARGO_FEATURE_MIMXRT") || x.starts_with("CARGO_FEATURE_LPC"))
        .get_one()
    {
        Ok(x) => x,
        Err(GetOneError::None) => panic!("No mimxrt/lpc Cargo feature enabled"),
        Err(GetOneError::Multiple) => panic!("Multiple mimxrt/lpc Cargo features enabled"),
    }
    .strip_prefix("CARGO_FEATURE_")
    .unwrap()
    .to_ascii_lowercase();

    let singletons = singletons(&mut cfgs);

    cfg_aliases! {
        rt1xxx: { any(feature = "mimxrt1011", feature = "mimxrt1062") },
    }

    cfg_aliases! {
        lpc55: { any(feature = "lpc55s16", feature = "lpc55-core0") },
    }

    eprintln!("chip: {chip_name}");

    generate_code(&mut cfgs, &singletons);

View on GitHub (pinned to 463a07b963)