Async GPIO interrupts on task running on app core

[cgudrian]

Hello!

I have two executors running, one on core 0 and one on core 1. Timer events work as expected. GPIO events, however, only work, if the task runs on the executor on core 0. Browsing through the implementation in gpio/mod.rs I didn't find an obvious reason why this shouldn't work.

This is how I initialize embassy, the IO pin and the executor on core 1:

    let io = Io::new(peripherals.GPIO, peripherals.IO_MUX);
    let button = AnyInput::new(io.pins.gpio4, Pull::None);

    let timg1 = TimerGroup::new(peripherals.TIMG1, &clocks);
    let timer0: ErasedTimer = timg1.timer0.into();
    let timer1: ErasedTimer = timg1.timer1.into();
    esp_hal_embassy::init(&clocks, [timer0, timer1]);

    let mut cpu_control = CpuControl::new(peripherals.CPU_CTRL);
    let stack = mk_static!(cpu_control::Stack<2048>, cpu_control::Stack::new());
    let _guard = cpu_control
        .start_app_core(stack, move || {
            let executor = mk_static!(Executor, Executor::new());
            executor.run(|spawner| {
                spawner.spawn(app_task(button)).ok();
            });
        })
        .unwrap();

And here's the implementation of app_task:

#[embassy_executor::task]
async fn app_task(mut button: AnyInput<'static>) {
    info!("Starting app_task() on core {}", get_core() as usize);
    loop {
        button.wait_for_low().await;
        info!("Button is pressed.");
        button.wait_for_high().await;
        info!("Button is released.");
    }
}

What am I missing?

Christian

[bugadani]

Yeah this might be an oversight on our part, GPIO interrupts are only handled by the first core at the moment. The interrupt handler is bound to the first core (more precisely, where you call Io::new()), so the second core doesn't get the requests.

[bugadani]

On ESP32 GPIO has a separate interrupt status register for both cores. Core 0 may execute the interrupt handler, but it'll see nothing if core 1 is listening for the interrupt. This is a pretty confusing mechanism and I think it's been cleaned up for S3.

[cgudrian]

once INT_ENA is set on the second core, the first core should run the interrupt and wake the waker

That was my understanding of the code as well.

[cgudrian]

Core 0 may execute the interrupt handler, but it'll see nothing if core 1 is listening for the interrupt.

Would it suffice to just register the interrupt handler on core 1 as well?

[bugadani]

I think you can't do that because gpio_interrupt_handler is private. Moving Io::new() to core 1 is probably your best bet right now.

[Dominaezzz]

What am I missing?

What the log output of the code you pasted?

[cgudrian]

I (31) boot: ESP-IDF v5.1-beta1-378-gea5e0ff298-dirt 2nd stage bootloader
I (31) boot: compile time Jun  7 2023 07:48:23
I (33) boot: Multicore bootloader
I (37) boot: chip revision: v3.1
I (41) boot.esp32: SPI Speed      : 40MHz
I (46) boot.esp32: SPI Mode       : DIO
I (50) boot.esp32: SPI Flash Size : 4MB
I (55) boot: Enabling RNG early entropy source...
I (60) boot: Partition Table:
I (64) boot: ## Label            Usage          Type ST Offset   Length
I (71) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (79) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (86) boot:  2 factory          factory app      00 00 00010000 003f0000
I (94) boot: End of partition table
I (98) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=02d84h ( 11652) map
I (111) esp_image: segment 1: paddr=00012dac vaddr=3ffb0000 size=0000ch (    12) load
I (115) esp_image: segment 2: paddr=00012dc0 vaddr=40080000 size=015cch (  5580) load
I (126) esp_image: segment 3: paddr=00014394 vaddr=00000000 size=0bc84h ( 48260) 
I (149) esp_image: segment 4: paddr=00020020 vaddr=400d0020 size=06b88h ( 27528) map
I (160) boot: Loaded app from partition at offset 0x10000
I (160) boot: Disabling RNG early entropy source...
INFO - Starting app_task() on core 1

[cgudrian]

Thank you all for your quick support!