What causes "unwrap of `{}` failed: {:?}" in embassy-rs/embassy?

Read the `{:?}` error in the panic message — it names the underlying Err that caused the unwrap to fail

unwrap of ` ` failed

Error message

unwrap of `{}` failed: {:?}

What it means

This is embassy's own `unwrap!` macro (in embassy-nrf/src/fmt.rs) panicking when the wrapped expression evaluates to Err (or None via `Try::into_result`). It exists so embedded firmware can unwrap Results/Options while still logging the expression text and error value. The panic message includes the original expression source (`{}` via stringify!) and the Debug-formatted error, so the actual failure cause is whatever the inner call returned.

Solutions

Read the `{:?}` error in the panic message — it names the underlying Err that caused the unwrap to fail
Replace `unwrap!(...)` at the failing call site with explicit `match`/`?` handling and log or recover from the error
Check that the peripheral/config passed to the failing call is valid for your chip variant and feature flags
If it fails at init, verify pins, buffers, and clock configuration against the datasheet

Example fix

// before
unwrap!(uarte.write(&buf).await);
// after
if let Err(e) = uarte.write(&buf).await {
    defmt::error!("uarte write failed: {:?}", e);
    return;
}

Defensive patterns

Strategy: try-catch

Try / catch

// Replace unwrap! with explicit handling:
// match op() {
//     Ok(v) => v,
//     Err(e) => { defmt::error!("op failed: {:?}", e); return Err(e); }
// }

Prevention

Prefer `?` or explicit match over unwrap! in application code
Log the Debug error from the panic message to identify the root cause
Validate peripheral configs (pins, buffers, enums) before calls that unwrap
Add unit/integration tests for fallible driver calls on your exact chip variant

When it happens

Trigger: Any call site in embassy-nrf (or user code importing this macro) using `unwrap!(expr)` where expr returns an Err — e.g. `unwrap!(uarte.write(b"x"))` failing with a peripheral error, `unwrap!(slice.fill_bytes(...))`, failed IPC/channel receives, or invalid peripheral configuration returning Err at init.

Common situations: Wrong pin/peripheral configuration at init time; passing buffers violating driver invariants; interrupt or channel receive failures when a sender was dropped; calling driver methods with invalid enum values for the specific chip variant.

Related errors

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

Appendix: source

Thrown at embassy-nrf/src/fmt.rs:202

    };
}

#[cfg(feature = "defmt")]
#[collapse_debuginfo(yes)]
macro_rules! unwrap {
    ($($x:tt)*) => {
        ::defmt::unwrap!($($x)*)
    };
}

#[cfg(not(feature = "defmt"))]
#[collapse_debuginfo(yes)]
macro_rules! unwrap {
    ($arg:expr) => {
        match $crate::fmt::Try::into_result($arg) {
            ::core::result::Result::Ok(t) => t,
            ::core::result::Result::Err(e) => {
                ::core::panic!("unwrap of `{}` failed: {:?}", ::core::stringify!($arg), e);
            }
        }
    };
    ($arg:expr, $($msg:expr),+ $(,)? ) => {
        match $crate::fmt::Try::into_result($arg) {
            ::core::result::Result::Ok(t) => t,
            ::core::result::Result::Err(e) => {
                ::core::panic!("unwrap of `{}` failed: {}: {:?}", ::core::stringify!($arg), ::core::format_args!($($msg,)*), e);
            }
        }
    }
}

#[derive(Debug, Copy, Clone, Eq, PartialEq)]
pub struct NoneError;

pub trait Try {
    type Ok;

View on GitHub (pinned to 463a07b963)