Blinking an LED in ULP crashes when an external interrupt is setup from the main CPU

[DylanWork]

Hi all,

I have been attempting to set up a button press interrupt from the main CPU (easily done) while having the ULP still running.

I have run into an unexpected issue with using the function:
esp_sleep_enable_ext0_wakeup(Button, 0);

The ULP program is:

Code: Select all

[Codebox=c file=Untitled.c]
int main (void)
{
    if (counter_state_for_ULP % 16 == 0) //Blink the LED every 4 seconds (ULP is setup to run every 250ms)
    {
        example_ulp_gpio_init(Membrane_LED_Yellow); //Intiate Yellow LED
        example_ulp_gpio_output_enable(Membrane_LED_Yellow); //Enable output
        example_ulp_gpio_output_level(Membrane_LED_Yellow, 1); //Set HIGH
        wait(150000);//Small delay
        example_ulp_gpio_output_level(Membrane_LED_Yellow, 0); //Set LOW
    }
 }
[/Codebox]

The main function in ULP works when "esp_sleep_enable_ext0_wakeup(Button, 0);" is commented out in the main processor, but crashes when its enabled (the interrupt function continues to work after the crash, doesn't work when commented out for obvious reasons).

The functions example_ulp_gpio_xxxx can be found here:
https://github.com/espressif/esp-idf/tr ... /gpio/main

The reason I know the processor is crashing is because it wakes up after about 3 flashes with the cause = ESP_SLEEP_WAKEUP_COCPU_TRAP_TRIG

Which is described here as a crash

Any idea how enabling an interrupt can crash the co-processor while doing basic LED operations?

Any help would be greatly appreciated.
Cheers

[DylanWork]

Hi all,

I am still having trouble with this.

I have replicated this issue here:
https://github.com/DylanGWork/esp32s2ulp-interrupt

This shows the ULP co-processor either having an interrupt, or working code in the ULP co-processor, but not both at the same time.

It seems as though I can't have an interrupt while working with the ULP, this seems odd as I imagine it would be a very common situation.

I understand that support for ULP based interrupts is coming but not available, if you have a very good understanding of how to implement ULP code, feel free to point me in the right direction for implementing Section 1.6.3 here:
https://www.espressif.com/sites/default ... ual_en.pdf

I'm not sure what other options I have here, so any ideas would be appreciate.

Cheers

[DylanWork]

Hi all,

This issue has been resolved.

This issue is related to the ESP32-S2 board and its compatibility with current esp-idf (I'm using V4.4).

To get this working on an ESP32-S2, you need to modify the file sleep_modes.c as follows:

Code: Select all

typedef struct {
    esp_sleep_pd_option_t pd_options[ESP_PD_DOMAIN_MAX];
    uint64_t sleep_duration;
    uint32_t wakeup_triggers : 15;
    uint32_t ext1_trigger_mode : 1;
    uint32_t ext1_rtc_gpio_mask : 22; //Change from 18 to 22
    uint32_t ext0_trigger_level : 1;
    uint32_t ext0_rtc_gpio_num : 5;
    uint32_t gpio_wakeup_mask : 6;
    uint32_t gpio_trigger_mode : 6;
    uint32_t sleep_time_adjustment;
    uint32_t ccount_ticks_record;
    uint32_t sleep_time_overhead_out;
    uint32_t rtc_clk_cal_period;
    uint64_t rtc_ticks_at_sleep_start;
} sleep_config_t;

This change means that GPIO's 18-21 will now work for the interrupt mask.

Is there a way we can report/request this is changed in the esp-idf framework?

We have also come across errors in the ESP32-S2 API guide, it would appear that the additional GPIOs are not updated from ESP32 -> ESP32-S2

We are also making progress on getting interrupts working in the ULP risc-v co-processor, I'll update this topic when that happens and make the code available in the github I've posted.

Cheers

[twicejiggled]

Hey, any updates for implementing interrupts on the ULP?

I'm hoping to migrate my program from the esp32 which utilises a core for handling and streaming Wi-Fi data and another core for handling and receiving data from peripheral devices (spi, i2c) and was hoping to implement a bit-banged spi with gpio interrupt on the ULP so i can keep the main core for handling Wi-Fi data, so if you've found any resources that have been particularly useful they'd be greatly appreciated.