When enabling interrupts and using clocks, ESP32 runs for 18 seconds and hangs

[yanshay]

Hi, I'm trying to use interrupts with ESP32. Once I enable interrups when using clocks, after some time (consistently 18 seconds of simple looping and logging) the device stops/hangs.

This to related to the combination of clocks enabling interrupts because if I disable all interrupts or don't create the clocks (ClockControl) then device continues to work.
I'm using ESP32 basic version, I tried disabling the watchdogs of both timer groups and the rtc, but it still happens.
It happens on two different ESP32 boards.

• What am I doing wrong/missing?
• I think it's an unhandled interrupt, how can I identify which interrupt is triggered? I tried quite a few but none were triggered.

This is the code that reproduces the issue, nothing special about it:

• This counts until 18 and stops.
• If I comment the 'Disable the RTC' section that disables watchdogs, same behavior.
• If I remove the clocks (need to then remove delay as well and its usage) then it works fine.
• If I remove the unsafe interrupt enable, also works fine.

#![no_std]
#![no_main]

extern crate alloc;
use core::mem::MaybeUninit;
use esp_backtrace as _;
use esp_println::println;
use hal::{clock::ClockControl, peripherals::{Peripherals, self}, prelude::*, Delay, IO, Rtc, timer::TimerGroup};

#[global_allocator]
static ALLOCATOR: esp_alloc::EspHeap = esp_alloc::EspHeap::empty();

fn init_heap() {
    const HEAP_SIZE: usize = 32 * 1024;
    static mut HEAP: MaybeUninit<[u8; HEAP_SIZE]> = MaybeUninit::uninit();

    unsafe {
        ALLOCATOR.init(HEAP.as_mut_ptr() as *mut u8, HEAP_SIZE);
    }
}
#[entry]
fn main() -> ! {
    let peripherals = Peripherals::take();
    let system = peripherals.SYSTEM.split();
    let io = IO::new(peripherals.GPIO, peripherals.IO_MUX);

    let clocks = ClockControl::max(system.clock_control).freeze();
    let mut delay = Delay::new(&clocks);

    // setup logger
    // To change the log_level change the env section in .cargo/config.toml
    // or remove it and set ESP_LOGLEVEL manually before running cargo run
    // this requires a clean rebuild because of https://github.com/rust-lang/cargo/issues/10358
    esp_println::logger::init_logger_from_env();
    log::info!("Logger is setup");
    println!("Hello world!");

    // Disable the RTC and TIMG watchdog timers
    let mut rtc = Rtc::new(peripherals.RTC_CNTL);
    let mut timer_group0 = TimerGroup::new(
        peripherals.TIMG0,
        &clocks,
        // removed: &mut system.peripheral_clock_control, // not available in esp32
    );
    let mut wdt0 = timer_group0.wdt;

    let mut timer_group1 = TimerGroup::new(
        peripherals.TIMG1,
        &clocks,
        // removed: &mut system.peripheral_clock_control, // not available in esp32
    );
    let mut wdt1 = timer_group1.wdt;

    // removed: rtc.swd.disable(); // fn not found in esp32 (not c2) // not available in esp32
    rtc.rwdt.disable(); // every 10 sec or so
    wdt0.disable(); // every sec or so
    wdt1.disable(); 
    timer_group0.timer0.unlisten();
    timer_group0.timer1.unlisten();
    timer_group1.timer0.unlisten();
    timer_group1.timer1.unlisten();

    rtc.rwdt.unlisten();

    unsafe {
        hal::xtensa_lx::interrupt::enable();
    }

    let mut counter = 0;
    loop {
        counter += 1;
        println!("Loop...{}", counter);
        delay.delay_ms(1000u32);
    }
}

[bjoernQ]

Basically hal::xtensa_lx::interrupt::enable() just enables all CPU interrupts (see TRM chapter "2.3.2 CPU Interrupt") which includes interrupts Timer,0, Timer.1, Timer.2 which are CPU internal timers. One of them will wrap/overflow shortly after your counter gets to 18.

Those interrupts are unhandled. There is currently no good way to notice that (while unhandled peripheral interrupts should give you a log message).

But for using interrupts calling hal::xtensa_lx::interrupt::enable() yourself is unnecessary since enable_interrupt will enable the correct interrupt for you.

If I remove the clocks (need to then remove delay as well and its usage) then it works fine.

This wouldn't make sense giving my explanation above and indeed it will freeze but without the delay the counter gets to Loop...48275

One question: Where did you find hal::xtensa_lx::interrupt::enable()? If we are giving a wrong advise somewhere we should fix that

[yanshay]

One question: Where did you find hal::xtensa_lx::interrupt::enable()? If we are giving a wrong advise somewhere we should fix that

I found this here - https://dev.to/apollolabsbin/esp32-embedded-rust-at-the-hal-gpio-button-controlled-blinking-1p93 (under Enable global interrupts). That doesn't seem to be your material, but jumps high on google

The article refers to ESP32C so maybe there's a difference between how things should be done there?

I tried your guidelines now to enable only the GPIO interrupt, this is what I ended up with, is that the correct way to enable the interrupts? function name was different from enable_interrupt but I think I found the correct one interrupt::enable:

    let mut touch_interrupt = io.pins.gpio36.into_pull_up_input();
    touch_interrupt.listen(hal::gpio::Event::FallingEdge);
    interrupt::enable(hal::peripherals::Interrupt::GPIO, interrupt::Priority::Priority1);

It's indeed working, but I'm not sure I fully understand how that would work in the general case:

• listen defines which pin triggers an interrupt and when (FallingEdge in this case)
• interrupt::enable enables all GPIO interrupts (so can't enable/disable per pin, but can probably unlisten instead - I'm not sure I understand the difference between listen and enable, why need both, could always enable GPIO interrupts and leave it to the user to only deal with listen/unlisten)
• Handler is defined for all GPIOs that may trigger, and I need to check in the code which did by checking the pin?

But how can I tell which gpio triggered if several could and I want to trigger on AnyEdge (so can't even tell based on the pin level)? Is there an api to check from within an interrupt what triggered it? Maybe it's somewhere in the CPU Context structure that's in the handler signature?

[bjoernQ]

Oh yes apollolabsbin is quite popular but we are in loose contact to the author so we probably should get that changed. Thanks!

There is only one GPIO interrupt, that is right. interrupt::enable will enable that interrupt so when the GPIO asserts an interrupt it is routed to your interrupt handler.

listen on a pin will make that pin raise an interrupt

So basically, when the interrupt is enabled but no pin is listening nothing will happen. The other way around, call listen on a pin and not enabling the interrupt would also do nothing.

In fact, there was an API for checking if a specific pin did raise the interrupt but it seems it got lost during some refactoring. I will create an issue for getting it back - thanks for bringing this up

[bjoernQ]

Issue created: #923

BTW a good source of information is also the examples folder in this repository: https://github.com/esp-rs/esp-hal/tree/main/esp32-hal/examples

[yanshay]

Awesome, Thanks for all the support!

[yanshay]

The challenge with your examples is that it's difficult to reproduce them in my own project due to the relatively complex dependencies/features across several Cargo.toml.
For example, now I'm trying to figure how to use embassy and what dependencies/features are required, from these Cargo.toml's there, at least initially, it seem pretty difficult to tell.

[bjoernQ]

Yes, we are aware of this and our plan is to extend the template (esp-rs/esp-template) to generate a few different typical configurations. Thanks for the feedback

[yanshay]

Found another reference to the use of that unsafe code in an example on your repo:

https://github.com/esp-rs/no_std-training/blob/8a2607a9a86ac09f841d6ccc177eaf4297b3df7a/intro/button-interrupt/examples/button-interrupt.rs#L40