Interrupt wdt on Uninstall CAN driver

[brp80000]

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

1.jpg (213.8 KiB) Viewed 9054 times

[ESP_Dazz]

Could you decode the backtrace please

[brp80000]

Could you decode the backtrace please

tell me how to do it?

[brp80000]

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

[ESP_Dazz]

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:

Code: Select all

cd $MY_PROJECT_WORKSPACE/hello_world
xtensa-esp32-elf-addr2line -e build/hello-world.elf 0x40087cc0:0x3ffbcc70 0x4008871d:0x3ffbcc90 0x40089cec:0x3ffbccb0 0x4 0089ca2:0xa5a5a5a5

Do this for the both backtraces

[brp80000]

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

1.jpg (183.49 KiB) Viewed 9025 times

[ESP_Dazz]

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

[brp80000]

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

[ESP_Dazz]

@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).

[brp80000]

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.