xQueueSendToBackFromISR causes Interrupt watchdog timeout

jcolebaker
Posts: 64
Joined: Thu Mar 18, 2021 12:23 am

xQueueSendToBackFromISR causes Interrupt watchdog timeout

Postby jcolebaker » Thu Nov 02, 2023 2:09 am

I have a custom ISR for UART:

Code: Select all

static void IRAM_ATTR uart_isr_handler(void* arg)
{
    (void)(arg); // Unused

    uint16_t bytes_available = UART1.status.rxfifo_cnt;
    for (uint16_t i = 0; i < bytes_available; i++)
    {
        uint8_t data = (uint8_t)UART1.fifo.rw_byte;
        MessagesHandleReceivedByteISR(data);
    }

    // Clear interrupt flags:
    uart_clear_intr_status(UART_NUM_1, UART_RXFIFO_FULL_INT_CLR | UART_RXFIFO_TOUT_INT_CLR);
}
And in another component, the function to receive characters and decode, using a local static struct for buffered characters and state. "MessageAddChr" is pretty simple and fast, and does some byte checking and manipulation to check for valid messages. Not shown here, for brevity. The MsgT struct is about 60 bytes:

Code: Select all

typedef struct
{
    uint8_t len;
    bool msg_on_hold;
    uint8_t buffer[BUFFER_SIZE],
    //... Etc.
} MsgT;

static MsgT l_incoming_message;

void MessagesHandleReceivedByteISR(uint8_t data)
{
    XpRxResultT result = MessageAddChr(&l_incoming_message, data);
        // Sets "msg_on_hold" to true when a complete message has been received and decoded.

    if (!l_incoming_message.msg_on_hold) return;


    BaseType_t higher_priority_task_woken = pdFALSE;

    xQueueSendToBackFromISR(l_rx_queue, &l_incoming_message, &higher_priority_task_woken);

    (void)(higher_priority_task_woken); // Unused, for now.

    MessageInit(&l_incoming_message); // Reset the message struct.
}
This works fine if I comment out the line "xQueueSendToBackFromISR(...)"

However, if I enable the line, the code hangs and then reboots with an interrupt watchdog timeout error:

Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0).

It looks like writing to the queue is blocking the function and thus the ISR. Why would "xQueueSendToBackFromISR" cause this code to hang? Note I have another task which is reading the messages from the queue, but I don't know why that would make a difference.

We are using ESP-IDF v4.4.4.

ESP_Sprite
Posts: 9711
Joined: Thu Nov 26, 2015 4:08 am

Re: xQueueSendToBackFromISR causes Interrupt watchdog timeout

Postby ESP_Sprite » Thu Nov 02, 2023 5:06 pm

I doubt it's that, the *FromISR functions specifically never block as they're supposed to be called in an interrupt. Does the core dump from the watchdog interrupt panic tell you where the CPU is hung?

jcolebaker
Posts: 64
Joined: Thu Mar 18, 2021 12:23 am

Re: xQueueSendToBackFromISR causes Interrupt watchdog timeout

Postby jcolebaker » Thu Nov 02, 2023 6:47 pm

Here is the error info printed out by the monitor command:

Code: Select all

Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0). 

Core  0 register dump:
PC      : 0x4008492a  PS      : 0x00050035  A0      : 0x401a486a  A1      : 0x3ffbebc0
0x4008492a: _xt_lowint1 at C:/Users/Jeremycb/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1114

0x401a486a: esp_pm_impl_waiti at C:/Users/Jeremycb/esp-idf/components/esp_pm/pm_impl.c:839

A2      : 0x00001000  A3      : 0x3ffbc700  A4      : 0x0000103f  A5      : 0x3ffbeb90
A6      : 0x00000000  A7      : 0x3ff50000  A8      : 0x00000000  A9      : 0x4009394e
0x4009394e: _frxt_int_enter at C:/Users/Jeremycb/esp-idf/components/freertos/port/xtensa/portasm.S:119

A10     : 0x00000000  A11     : 0x40001d48  A12     : 0x800851bf  A13     : 0x3ffbeb60
A14     : 0x00000000  A15     : 0x00000101  SAR     : 0x0000001f  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000
Core  0 was running in ISR context:
EPC1    : 0x400989c7  EPC2    : 0x00000000  EPC3    : 0x401a486a  EPC4    : 0x400d6594
0x400989c7: uart_hal_write_txfifo at C:/Users/Jeremycb/esp-idf/components/hal/uart_hal_iram.c:35

0x401a486a: esp_pm_impl_waiti at C:/Users/Jeremycb/esp-idf/components/esp_pm/pm_impl.c:839

0x400d6594: uart_ll_get_txfifo_len at C:/Users/Jeremycb/esp-idf/components/hal/esp32/include/hal/uart_ll.h:321 (discriminator 1)
 (inlined by) uart_tx_char at C:/Users/Jeremycb/esp-idf/components/vfs/vfs_uart.c:156 (discriminator 1)



Backtrace: 0x40084927:0x3ffbebc0 0x401a4867:0x3ffbc700 0x400d4eca:0x3ffbc720 0x4009532d:0x3ffbc740 0x40097925:0x3ffbc760
0x40084927: _xt_lowint1 at C:/Users/Jeremycb/esp-idf/components/freertos/port/xtensa/xtensa_vectors.S:1114

0x401a4867: cpu_ll_waiti at C:/Users/Jeremycb/esp-idf/components/hal/esp32/include/hal/cpu_ll.h:183
 (inlined by) esp_pm_impl_waiti at C:/Users/Jeremycb/esp-idf/components/esp_pm/pm_impl.c:837

0x400d4eca: esp_vApplicationIdleHook at C:/Users/Jeremycb/esp-idf/components/esp_system/freertos_hooks.c:63

0x4009532d: prvIdleTask at C:/Users/Jeremycb/esp-idf/components/freertos/tasks.c:3987 (discriminator 1)

0x40097925: vPortTaskWrapper at C:/Users/Jeremycb/esp-idf/components/freertos/port/xtensa/port.c:142



Core  1 register dump:
PC      : 0x401a486a  PS      : 0x00060135  A0      : 0x800d4ecd  A1      : 0x3ffbce60
0x401a486a: esp_pm_impl_waiti at C:/Users/Jeremycb/esp-idf/components/esp_pm/pm_impl.c:839

A2      : 0x00000000  A3      : 0x3ffbc960  A4      : 0x80000000  A5      : 0x00000001
A6      : 0x00000003  A7      : 0x00060023  A8      : 0x8012b3f2  A9      : 0x3ffbce30
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x80097c11  A13     : 0x3ffbcd70
A14     : 0x00000003  A15     : 0x00060023  SAR     : 0x00000000  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000

0x401a4867: cpu_ll_waiti at C:/Users/Jeremycb/esp-idf/components/hal/esp32/include/hal/cpu_ll.h:183
 (inlined by) esp_pm_impl_waiti at C:/Users/Jeremycb/esp-idf/components/esp_pm/pm_impl.c:837

0x400d4eca: esp_vApplicationIdleHook at C:/Users/Jeremycb/esp-idf/components/esp_system/freertos_hooks.c:63

0x4009532d: prvIdleTask at C:/Users/Jeremycb/esp-idf/components/freertos/tasks.c:3987 (discriminator 1)

0x40097925: vPortTaskWrapper at C:/Users/Jeremycb/esp-idf/components/freertos/port/xtensa/port.c:142

jcolebaker
Posts: 64
Joined: Thu Mar 18, 2021 12:23 am

Re: xQueueSendToBackFromISR causes Interrupt watchdog timeout

Postby jcolebaker » Thu Nov 02, 2023 11:45 pm

Hmm, the stack trace etc above seems to indicate there is a problem on the UART Transmit side. When I push messages to a queue, they eventually trigger another task to send a reply on the UART. I expected the receive interrupt handler to complete once the message was pushed to a queue, so I was hoping the subsequent code wasn't relevant. However, it is fair to say that the system is more complex than what is represented here. Also, we are using external PSRAM. The UART ISR is in IRAM, but other code and data may not be, so that could be causing issues with the flash cache.

I admit I don't have enough experience with ESP interrupt handlers, so I need to create a simpler design to gain a better understanding!

Who is online

Users browsing this forum: Gaston1980 and 83 guests