xTaskNotifyFromISR / xTaskNotifyWait pair causes error (IDFGH-12088)

[xarrange]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

ESP-IDF v5.1.2

Espressif SoC revision.

ESP32-C3

Operating System used.

Windows

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

CMD

Development Kit.

cusome board

Power Supply used.

USB

What is the expected behavior?

I expect system to restart when I press the button that sets GPIO4 input to "1".

What is the actual behavior?

I get error in multiple files

Steps to reproduce.

Here is my piece of code:

static TaskHandle_t taskBTNReset;

static void IRAM_ATTR reset_button_isr_handler(void* arg)
{
	xTaskNotifyFromISR( taskBTNReset, 0, eNoAction, NULL);
}

static void task_btn_reset(void* param) 
{	
	printf("Wating for notification\n");
	xTaskNotifyWait( 0,0, NULL, portMAX_DELAY );	
	
	printf("Restarting...\n");	
	
	esp_restart();
}
void app_main(void)
{

	gpio_config_t io_conf;
	io_conf.intr_type = GPIO_INTR_POSEDGE;
	io_conf.mode = GPIO_MODE_INPUT;
	io_conf.pin_bit_mask = (uint64_t)((uint64_t)(((uint64_t)1)<<4));
	io_conf.pull_down_en = GPIO_PULLDOWN_ENABLE;
	io_conf.pull_up_en = GPIO_PULLUP_DISABLE ;
	gpio_config(&io_conf);
	
	gpio_set_intr_type(4, GPIO_INTR_POSEDGE);
	
	gpio_install_isr_service(ESP_INTR_FLAG_EDGE | ESP_INTR_FLAG_IRAM);    
	gpio_isr_handler_add(4, reset_button_isr_handler, NULL);
	
	xTaskCreate( task_btn_reset, "reset_task", 2048, NULL, 28, &taskBTNReset);
}

Debug Logs.

Wating for notification
E (14917) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (14917) task_wdt:  - IDLE (CPU 0)
E (14917) task_wdt: Tasks currently running:
E (14917) task_wdt: CPU 0: reset_task
E (14917) task_wdt: Print CPU 0 (current core) registers
Core T8 register dump:
MEPC    : 0x403868f4  RA      : 0x4038691e  SP      : 0x3fc939c0  GP      : 0x3fc8c000
0x403868f4: vPortClearInterruptMask at C:/Espressif/frameworks/esp-idf-v5.1.2/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:385
0x4038691e: vPortExitCritical at C:/Espressif/frameworks/esp-idf-v5.1.2/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:339

TP      : 0x3fc8ac10  T0      : 0x00000000  T1      : 0x00000000  T2      : 0x00000000
S0/FP   : 0x00000000  S1      : 0xffffffff  A0      : 0x00000001  A1      : 0x00000001
A2      : 0x00000000  A3      : 0x00000004  A4      : 0x3fc8f000  A5      : 0x600c2000
A6      : 0x42005724  A7      : 0x00000000  S2      : 0x00000000  S3      : 0x00000000
0x42005724: console_write at C:/Espressif/frameworks/esp-idf-v5.1.2/components/vfs/vfs_console.c:71

S4      : 0xffffffff  S5      : 0x00000000  S6      : 0x00000000  S7      : 0x00000000
S8      : 0x00000000  S9      : 0x00000000  S10     : 0x00000000  S11     : 0x00000000
T3      : 0x00000000  T4      : 0x00000000  T5      : 0x00000000  T6      : 0x00000000
MSTATUS : 0x00000000  MTVEC   : 0xffffffff  MCAUSE  : 0x00000000  MTVAL   : 0x40386284
0x40386284: xTaskGenericNotifyWait at C:/Espressif/frameworks/esp-idf-v5.1.2/components/freertos/FreeRTOS-Kernel/tasks.c:5913

More Information.

No response

[sudeep-mohanty]

Hello @xarrange,
Thanks for reporting this issue to us. I could reproduce the problem at my end. Upon initial investigation , it looks like a problem with the interrupt being registered with the interrupt allocation flag ESP_INTR_FLAG_EDGE. Seems like the CPU edge type interrupt is not cleared and keeps triggering, leading to a watchdog timeout. The quickworkaround for your problem would be to register the ISR without this flag, viz.,

gpio_install_isr_service(ESP_INTR_FLAG_IRAM);

Meanwhile, we will investigate the issue further and keep this ticket posted.

[xarrange]

Indeed removing this flag totally fixes the issue. Thanks!

[AxelLin]

@songruo @sudeep-mohanty Any further update about #13146 (comment) ?

[songruo]

For ESP-RISC-V CPU, it would latch the state of an "edge" type CPU interrupt signal on its rising edge (see Technical Reference Manual > ESP-RISC-V CPU > Interrupt Controller > Functional Description). Therefore, it needs to be manually cleared with WRITE_PERI_REG(INTERRUPT_CORE0_CPU_INT_CLEAR_REG, 1 << int_no). "level" type interrupts are not latched in the interrupt matrix, they are simply ORed, so no manual clear of the status bits are required.