WDT interrupt caused by the eternal circle in the serial interrupt handler

[Antdigapony]

Hardware:

Board	ESP32 Dev Module
Version/Date	2018-2019 not sure
IDE name	VSCode
Flash Frequency	240Mhz - CPU, 80 Mhz - APB
PSRAM enabled	no
Upload Speed	921600
Serial Baudrate for the Sensor	115200
Chip Version	Silicon Revision 1
Computer OS	Ubuntu

Description:

My question is: I have the sensor, which is connected to the ESP. This device always sends the data, when it's turned on, even if the ESP is turned off or sleeping. So, the problem is when I start to init the Serial for that device in the ESP code.
In other words - when I start the HardwareSerial.begin() it starts the uartBegin() method in the esp32-hal-uart.c it starts in it's turn the uartAttachRx() method in the same esp32-hal-uart.c and here is a problem: the uartEnableInterrupt() method starts only after the rx pinMode was changed to the INPUT, and when the data is already there - the interrupt happens immediately - and the code becomes locked inside the uartEnableInterrupt() method and it's mutex. That causes the WDT running out and Guru Meditation Error and the unwished rebooting.

So, at my local machine, I put the uartEnableInterrupt() method before the rx pinMode() setting and the bug disappeared, but I don`t exactly know if it is right to change the core's files in that way, so please, check up - maybe it will be useful.)))

Sketch:

void uartAttachRx(uart_t* uart, uint8_t rxPin, bool inverted)
{
    if(uart == NULL || rxPin > 39) {
        return;
    }
    pinMode(rxPin, INPUT);
    pinMatrixInAttach(rxPin, UART_RXD_IDX(uart->num), inverted);    
    uartEnableInterrupt(uart);
}

Debug Messages:

Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC      : 0x4017733a  PS      : 0x00060334  A0      : 0x800e5cb5  A1      : 0x3ffbcad0  
A2      : 0x00000000  A3      : 0x00000001  A4      : 0x00000000  A5      : 0x00000001  
A6      : 0x00060120  A7      : 0x00000000  A8      : 0x800e4cc2  A9      : 0x3ffbcaa0  
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x8008ec98  A13     : 0x3ffb5610  
A14     : 0x00000000  A15     : 0x3ffbc7c0  SAR     : 0x00000000  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  

ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000

Backtrace: 0x4017733a:0x3ffbcad0 0x400e5cb2:0x3ffbcaf0 0x40090261:0x3ffbcb10 0x4008ea85:0x3ffbcb30

Core 1 register dump:
PC      : 0x40081abf  PS      : 0x00050034  A0      : 0x40081e8c  A1      : 0x3ffbe970  
A2      : 0x3ffbdd24  A3      : 0x00000000  A4      : 0x00000001  A5      : 0x400911f8  
A6      : 0x00000004  A7      : 0x3ffd3e58  A8      : 0x00000000  A9      : 0x3ff40000  
A10     : 0x00000000  A11     : 0x00000001  A12     : 0x00000000  A13     : 0x3ffb1d60  
A14     : 0x3ffb8000  A15     : 0xbaad5678  SAR     : 0x0000001c  EXCCAUSE: 0x00000005  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000

Backtrace: 0x40081abf:0x3ffbe970 0x40081e89:0x3ffbe9a0 0x4000bfed:0x3ffb1db0 0x4008fc01:0x3ffb1dc0 0x400e64d3:0x3ffb1de0 0x400e6529:0x3ffb1e20 0x400e1a99:0x3ffb1e50 0x400e1b87:0x3ffb1e70 0x400e20a5:0x3ffb1e90 0x400dfb2e:0x3ffb1ed0 0x400d4b91:0x3ffb1f10 0x400d2e37:0x3ffb1f40 0x400dc00e:0x3ffb1f60 0x400e2336:0x3ffb1fb0 0x4008ea85:0x3ffb1fd0

Rebooting...

Backtrace :

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.