whitecatboard / Lua-RTOS-ESP32

Lua RTOS for ESP32
Other
1.18k stars 221 forks source link

A hardware interrupt signal caused a crash. #335

Closed guo652917087 closed 4 years ago

guo652917087 commented 4 years ago

Hi, Using the latest branch test, the configuration file of WHITECAT-ESP32-N1 was used. Several modifications were made: the second group of SPI was modified, and the three DIO mapped GPIOs were also modified. The test found that when the transmitting end sent lora data, the test SX126 received RF data and generated an interrupt signal to the DIO pin of the ESP, which caused a crash and the serial port could not be input or output, and the ESP32 must be restarted. When I enable CONFIG_INT_WDT, my sender sends a lora data, which will cause my ESP32 to restart and print the following log: board type N1ESP32

Lua RTOS beta 0.1 powered by Lua 5.3.4

Executing /system.lua ... Starting wifi ... Starting ethernet ... Starting sntp client ... Starting ssh server ... Starting http server ... Starting lora gateway ... Executing /autorun.lua ...

/ > Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0) Core 0 register dump: PC : 0x4009a760 PS : 0x00060934 A0 : 0x80099770 A1 : 0x3ffbf180
A2 : 0x3ffba34c A3 : 0x3ffbba3c A4 : 0x00000d0c A5 : 0x3f40a6a1
A6 : 0x0000cdcd A7 : 0x3ffbf2e0 A8 : 0x3ffbba3c A9 : 0x00000019
A10 : 0x3ffbba3c A11 : 0x00000019 A12 : 0x00000000 A13 : 0x00000001
A14 : 0x0000cdcd A15 : 0x00060223 SAR : 0x00000010 EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff
Core 0 was running in ISR context: EPC1 : 0x400989a3 EPC2 : 0x4021ee2e EPC3 : 0x00000000 EPC4 : 0x4009a760

ELF file SHA256: 9596447ff0b6f99fda0e77e24c2afcbc6187937e7500f8affbaea9ba049e1116

Backtrace: 0x4009a760:0x3ffbf180 0x4009976d:0x3ffbf1a0 0x40097dcf:0x3ffbf1c0 0x401a213e:0x3ffbf200 0x401a216c:0x3ffbf230 0x400883c5:0x3ffbf260 0x4008840f:0x3ffbf2e0 0x4008f873:0x3ffbf310 0x401ccbf1:0x3ffbf330 0x4008e832:0x3ffbf460 0x40085821:0x3ffbf490 0x4021ee2b:0x3ffbb940 0x400d1c93:0x3ffbb960 0x4009928d:0x3ffbb980

Core 1 register dump: PC : 0x40098106 PS : 0x00060034 A0 : 0x800987ae A1 : 0x3ffbbdc0
A2 : 0x3ffbe85c A3 : 0x00060023 A4 : 0x8009809e A5 : 0x3ffbfc50
A6 : 0x3ffbfc98 A7 : 0x00000001 A8 : 0x0000cdcd A9 : 0xb33fffff
A10 : 0x00060023 A11 : 0x0000cdcd A12 : 0x80099383 A13 : 0x0000abab
A14 : 0x00000020 A15 : 0x00000020 SAR : 0x0000001a EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000

ELF file SHA256: 9596447ff0b6f99fda0e77e24c2afcbc6187937e7500f8affbaea9ba049e1116

Backtrace: 0x40098106:0x3ffbbdc0 0x400987ab:0x3ffbbde0 0x4009a630:0x3ffbbe00 0x4009a5e6:0xa5a5a5a5

Rebooting...

guo652917087 commented 4 years ago

I located the problem because the execution did not exit for a long time in the interrupt, sx1276 received lora data, the radio generated an interrupt, and the program execution flow was dio_intr_handler-> get_irq_flags-> spi_ll_transfer (spi_device, SX1276_REG_IRQ_FLAGS & 0x7f, NULL); here we execute the exception , Did not return for a long time. I tested them on other task stacks:

gettimeofday (&before, NULL);    stx1276_read_buff (spi_device, SX1276_REG_IRQ_FLAGS, data, 1);    gettimeofday (&after, NULL);

The execution time of the above program stx1276_read_buff took about 2ms, which is far less than the timeout time of the interrupt (300ms). I don't know why the SPI can't perform the read and write operations of SX1276 in the interrupt?

guo652917087 commented 4 years ago

By modifying the code that I have to solve this problem, the issue is closed.