ESP32 Forum

Hi -

Any idea what this error means?

Unhandled interrupt 4 on cpu 0!

My system began throwing this (quite frequently) until the battery died.

Thanks...

It literally means what it says: somehow, interrupt number 4 got enabled without anyone registering a handler for it. This (obviously) normally shouldn't happen. I think interrupt 4 is normally used for the wireless base band, so if wifi is enabled, it should always be handled. Do you happen to do anything special with interrupts in your code yourself?

Hi Sprite -

Thanks for the reply. Regarding interrupt handling in my code, I do have one that monitors a GPIO.

May I ask where you derived the information that interrupt 4 is normally used with Wifi? If there's a list or some documentation, I'd be interested in reading it.

And, can I trap the first occurrence of this exception, and unwind the stack or something so I can get an idea of what happened?

Thanks.

Most interrupts nowadays are allocated dynamically using the interrupt allocator, but a few are still fixed: check esp-idf/components/soc/esp32/include/soc/soc.h for these. You can probably trap the first occurence of this by placing a breakpoint or something on the xt_unhandled_interrupt function, but I'm not sure how much info that'll give you as the interrupt invocation may be long past the offending code. It may be better to set a watchpoint on _xt_interrupt_table[4*2+0] (assuming you run in dual-core mode), as that entry contains a pointer to the current handler for interrupt 4 on core 0

Hi Sprite -

Thanks for the reply. I don't have a debugger, so breakpoints/watchpoints probably aren't possible for me. When I said "trap" I just meant catching it before it reboots, and going into an infinite loop or something.

Nice trick when you're in a pinch (or too lazy to get out the JTAG rig...): you can actually use breakpoints and watchpoints without a debugger as well, provided you don't mind not being able to continue when one is hit. If you set (in menuconfig) component config -> esp32 specific -> panic handler behaviour to 'start gdbstub' and use 'make monitor' as your serial monitor, whenever your app crashes, it'll dump you in a gdb session to inspect what went wrong. Now, the Xtensa architecture allows you to set watchpoints and breakpoints from your code (components/esp32/include/esp_panic.h, esp_set_watchpoint for watchpoints, something like asm("break.n 1") for a breakpoint) and without a jtag debugger attached, this will crash the program... landing you in the gdb debugger so you can find out the cause of the issue. So you debug this by enabling gdbstub, then modifying your program so after WiFi initialization it does something like esp_set_watchpoint(0, &_xt_interrupt_table[4*2+0], 4, ESP_WATCHPOINT_STORE); , then running 'make monitor' and waiting where the program crashes. That point will exactly be where the interrupt handler is reset, and the backtrace will show you the code pad that did it.

Don't forget to set the same watchpoint on both CPUs, if you don't know in advance which CPU does the code modifying xt_interrupt_table run on.