embassy-rs/embassy · critical

CORE1 not responding

Error message

CORE1 not responding

What it means

`Multicore::spawn_core1` boots the second core by pushing a sequence of stack/command words that core1's boot stub pops and echoes. The host core retries each word up to 16 times; if it observes more than 16 failed handshakes it concludes core1 is not executing the entrypoint stub and panics.

Solutions

1. Make sure spawn_core1 is called only once and core1 is in its reset/boot state before spawning
2. Provide a dedicated static stack buffer (correct size, 'static lifetime, not shared with other data)
3. Verify no other code is using the inter-core FIFOs/doorbells concurrently
4. Check core1 entry function signature and that the multicore feature/clock setup matches your chip (RP2040 vs RP235x)

Example fix

// before
fn main() {
    let mut mc = Multicore::new(...);
    mc.spawn_core1(&mut stack, move || task());
}
fn other_init() { mc.spawn_core1(...) } // second spawn can hang/panic
// after
fn init() {
    let mut mc = Multicore::new(...);
    mc.spawn_core1(&mut STACK, move || task()); // single spawn, static stack
}

static CORE1_SPAWNED: AtomicBool = AtomicBool::new(false);
assert!(!CORE1_SPAWNED.swap(true, Ordering::SeqCst), "core1 already spawned");

When it happens

Trigger: Calling `multicore.spawn_core1(core1_stack, entry)` while core1 fails to consume the boot sequence: core1 already running other code, core1 halted/reset by a debugger, corrupted stack memory, or inter-core FIFO contention from other code.

Common situations: Spawning core1 twice in one program; booting core1 while it is already running from a previous init; using a stack buffer that is dropped or overlaps other data; running under a debugger that holds core1 in reset.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

• Can only take the executor once
• DMA data error
• MCLK frequency < 9.5 MHz is not compatible with the TRNG
• Unknown value
• Invalid value

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

Appendix: source

Thrown at embassy-rp/src/multicore.rs:307

    let mut seq = 0;
    let mut fails = 0;
    loop {
        let cmd = cmd_seq[seq] as u32;
        if cmd == 0 {
            fifo_drain();
            cortex_m::asm::sev();
        }
        fifo_write(cmd);

        let response = fifo_read();
        if cmd == response {
            seq += 1;
        } else {
            seq = 0;
            fails += 1;
            if fails > 16 {
                // The second core isn't responding, and isn't going to take the entrypoint
                panic!("CORE1 not responding");
            }
        }
        if seq >= cmd_seq.len() {
            break;
        }
    }

    // Wait until the other core has copied `entry` before returning.
    fifo_read();

    // Enable fifo interrupt on CORE0 for `pend irq` functionality.
    #[cfg(all(feature = "rp2040", feature = "executor-interrupt"))]
    unsafe {
        interrupt::SIO_IRQ_PROC1.enable()
    };
    #[cfg(all(feature = "_rp235x", feature = "executor-interrupt"))]
    unsafe {
        interrupt::SIO_IRQ_FIFO.enable()

View on GitHub (pinned to 463a07b963)