Runtime ISR crash

[SnifMyBack]

Hi,
I've just updated my version of the ESP-IDF (3.3 beta) to the newest 3.3 LTS. As I was expecting (like any software you update), the new version make a new bug I'm not able to solve. The old version have a bug with the HTTP server, where it would crash at ramdom occasion (it's a documented bug). The new version is supposed to solve that but now I can't test it.

So the board starts without a problem but after a specific time the board abort itself. Here's the log I got:

Code: Select all

/esp-idf/components/driver/can.c:478 (can_intr_handler_main)- port*_CRITICAL called from ISR context!
abort() was called at PC 0x400f98c1 on core 0
0x400f98c1: can_intr_handler_main at C:/msys32/home/Sam/esp-idf/components/driver/can.c:810 (discriminator 2)


ELF file SHA256: 735751b68d50cab6cacbfb35710ca674fc70e159783fe3b371a22c2eccc57119

Backtrace: 0x400880cc:0x3ffb0620 0x40088319:0x3ffb0640 0x400f98c1:0x3ffb0660 0x400827a5:0x3ffb0690 0x400f49f5:0x3ffd6810 0x400f576c:0x3ffd6830 0x400f411b:0x3ffd6850 0x4000bd83:0x3ffd687
0 0x4000117d:0x3ffd6890 0x400592fe:0x3ffd68b0 0x4005937a:0x3ffd68d0 0x40058bbf:0x3ffd68f0 0x400dd34d:0x3ffd6920 0x400e2b36:0x3ffd6950 0x400e2c79:0x3ffd6c60 0x40082d69:0x3ffd6c90 0x400d4
f2b:0x3ffd6ce0 0x4008e4e1:0x3ffd6d10
0x400880cc: invoke_abort at C:/msys32/home/Sam/esp-idf/components/esp32/panic.c:715

0x40088319: abort at C:/msys32/home/Sam/esp-idf/components/esp32/panic.c:715

0x400f98c1: can_intr_handler_main at C:/msys32/home/Sam/esp-idf/components/driver/can.c:810 (discriminator 2)

0x400827a5: _xt_lowint1 at C:/msys32/home/Sam/esp-idf/components/freertos/xtensa_vectors.S:1154

0x400f49f5: uart_tx_char at C:/msys32/home/Sam/esp-idf/components/vfs/vfs_uart.c:141

0x400f576c: uart_write at C:/msys32/home/Sam/esp-idf/components/vfs/vfs_uart.c:141

0x400f411b: esp_vfs_write at C:/msys32/home/Sam/esp-idf/components/vfs/vfs.c:734 (discriminator 4)

0x400dd34d: __sprint_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf.c:437

0x400e2b36: _vfprintf_r at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vfprintf.c:1782 (discriminator 1)


0x400e2c79: vprintf at /Users/ivan/e/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdio/../../../.././newlib/libc/stdio/vprintf.c:39

0x40082d69: esp_log_write at C:/msys32/home/Sam/esp-idf/components/log/log.c:121

0x400d4f2b: obdRequest_task at C:/msys32/home/Sam/OBDModule/main/obd.c:932 (discriminator 6)

0x4008e4e1: vPortTaskWrapper at C:/msys32/home/Sam/esp-idf/components/freertos/port.c:403

The log points to this function:

Code: Select all

esp_err_t can_get_status_info(can_status_info_t *status_info)

I never had a problem with that and I'm trying to see why it crash. I'm using FreeRTOS, SPIFFS, CAN, http server, SoftAP, UART and maybe more...

My feeling is that when the CAN receive data, it must trigger an ISR and the code doesn't handle it for whatever reason. Maybe I'm wrong thought... So if anybody have an idea, I'll gladly take it.

[ESP_Sprite]

That's... well, if it's not a bug, it's pretty close to it. You can fix it by disabling FREERTOS_CHECK_PORT_CRITICAL_COMPLIANCE (menuconfig -> Component config -> FreeRTOS -> Tests compliance with Vanilla FreeRTOS port*_CRITICAL calls ). I'll raise an internal issue to make the CAN driver work without this as well.

[SnifMyBack]

That's... well, if it's not a bug, it's pretty close to it. You can fix it by disabling FREERTOS_CHECK_PORT_CRITICAL_COMPLIANCE (menuconfig -> Component config -> FreeRTOS -> Tests compliance with Vanilla FreeRTOS port*_CRITICAL calls ). I'll raise an internal issue to make the CAN driver work without this as well.

Thanks for the tips, it worked right away! I never thought at looking in the config file for possible solutions... Next time I'll remember it!