ESP32 Forum

I use esp-idf 3.2.2
my program switches the CAN bus speed many times. No data is transmitted. In doing so, I also start and stop the CAN bus monitoring and recovery Task. Several speed switches happen successfully, however then I get an error

Could you decode the backtrace please

ESP_Dazz wrote: ↑

Wed Oct 09, 2019 8:47 am

Could you decode the backtrace please

tell me how to do it?

Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC : 0x4008a5b8 PS : 0x00060634 A0 : 0x800889f7 A1 : 0x3f fce750
A2 : 0x3ffafe2c A3 : 0x3ffcea58 A4 : 0x3ffb245c A5 : 0x00 000001
A6 : 0x00060623 A7 : 0x3ffbed90 A8 : 0x3ffcea58 A9 : 0x3f fcea58
A10 : 0x00000014 A11 : 0x00000014 A12 : 0x00000000 A13 : 0x00 000001
A14 : 0x00060623 A15 : 0xff000000 SAR : 0x00000020 EXCCAUSE: 0x00 000005
EXCVADDR: 0x00000000 LBEG : 0x400014fd LEND : 0x4000150d LCOUNT : 0xff fffff8

Backtrace: 0x4008a5b8:0x3ffce750 0x400889f4:0x3ffce770 0x40089997:0x3ffce790 0x4 00d289a:0x3ffce7d0 0x400d294e:0x3ffce7f0 0x400d276e:0x3ffce810 0x400f08a1:0x3ffc e830 0x400d515a:0x3ffce850 0x400d5380:0x3ffce8a0 0x40124ddd:0x3ffce8d0 0x4014464 d:0x3ffce900 0x40124ff6:0x3ffce920 0x4012507c:0x3ffce980 0x4008904e:0x3ffce9b0

Core 1 register dump:
PC : 0x40087cc0 PS : 0x00060034 A0 : 0x80088720 A1 : 0x3f fbcc70
A2 : 0x3ffb2464 A3 : 0x00000000 A4 : 0x8008911a A5 : 0x3f fb1fc8
A6 : 0x3ffb2010 A7 : 0x00000001 A8 : 0x0000cdcd A9 : 0x00 00abab
A10 : 0xb33fffff A11 : 0x0000cdcd A12 : 0x800883ab A13 : 0x00 000001
A14 : 0x00060023 A15 : 0x00000001 SAR : 0x00000018 EXCCAUSE: 0x00 000005
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00 000000

Backtrace: 0x40087cc0:0x3ffbcc70 0x4008871d:0x3ffbcc90 0x40089cec:0x3ffbccb0 0x4 0089ca2:0xa5a5a5a5

Run xtensa-esp32-elf-addr2line and provide the project's .elf and backtrace addresses as arguments. The .elf file should be located somewhere in your project's build directory. For example:
Do this for the both backtraces

C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/driver/can.c:738

Would it be possible for you to post your .elf file. I want to see the full backtrace of both CPUs.

ESP_Dazz wrote: ↑

Wed Oct 09, 2019 9:34 am

Would it be possible for you to post your .elf file. I want to see the full backtrace of both CPUs.

# xtensa-esp32-elf-addr2line -e C:/Users/Alex/Desktop/workspace/esp32/build/ltc.elf 0x4008a5b8:0x3ffce750 0x400889f4:0x3ffce770 0x40089997:0x3ffce790 0x400d289a:0x3ffce7d0 0x400d294e:0x3ffce7f0 0x400d276e:0x3ffce810 0x400f08a1:0x3ffce830 0x400d515a:0x3ffce850 0x400d5380:0x3ffce8a0 0x40124ddd:0x3ffce8d0 0x4014464d:0x3ffce900 0x40124ff6:0x3ffce920 0x4012507c:0x3ffce980 0x4008904e:0x3ffce9b0
C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/freertos/list.c:188 (discriminator 1)
C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/freertos/tasks.c:4567
C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/freertos/queue.c:2374
C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/esp32/ipc.c:116
C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/esp32/ipc.c:128
C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/esp32/intr_alloc.c:720
C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/driver/can.c:738
............................................
C:/msys32/home/Alex/esp/esp-idf-v3.2.2/components/freertos/port.c:403

AND .elf file
https://yadi.sk/d/tDHMEodWfCIhEA

@brp80000 I think I see the issue.
When can_driver_uninstall() is called, internally it will deallocate the driver's interrupt by esp_intr_free(). However, if the interrupt was allocated on one core (e.g. Core 0), then freed by the other core (e.g. Core 1), esp_intr_free() will internally call esp_ipc_call_blocking() to run a callback on Core 0 to free the interrupt (since it was allocated on Core 0). However, esp_ipc_call_blocking() is a blocking function, and is run within the critical section of can_driver_uninstall() thus causing an interrupt watchdog timeout.

I'll open a JIRA ticket to fix this issue, but for now, you can circumvent this bug by ensuring that both can_driver_install() and can_driver_uninstall() are always called from the same core (by pinning the calling tasks).

Thanks, placing all the functions of can driver initialization, CAN start, CAN driver deinitialization, and can stop in one task, and binding this task to one CPU core solved the problem.