ESP32 Forum

Hey everyone,
I have been working on a rather large project. Recently I have been getting "unhandled interrupt 6 on core 0!"
After leaving it running for long period of time. Can't really pin down how long. It almost seems random.

I have read it could be a possible stack smash thats overwriting the interrupt pointer. So I have enabled stack smashing checks to see if that yields any info.

The stranger thing to me is, I get this error being printed over and over in the console. Yet some if my tasks continue running.

I have a LED that is blinked on and off with in a task and that led is still blinking. Though wifi stops working "no ssid can be seen"

I unfortunately have no idea at what point this issue was introduced as I haven't left this project running for more than a hour at a time since I been working on it.

Any suggestions on were to start or a Procedure to follow to narrow it down would be greatly appreciated.

Oh boy,this could become an "interesting" one...

From a glance, I glean that on the ESP32 the interrupt matrix is initialized to route all interrupt sources to CPU interrupt #6 (ETS_INVALID_INUM). This CPU interrupt get's hooked up to the "unhandled interrupt" handler which prints the message you see.
When you start initializing hardware and setting up interrupt handlers, the respective interrupts get routed to other CPU interrupts.

I believe you'll only end up with #6 if the interrupt never actually got re-routed/set up in the interrupt matrix.
One possibility for the issue to occur seems to be that somehow some interrupt got enabled on the wrong core, i.e. it was set up (via IDF/driver) on one core but not on the other core (which is how most interrupts should be set up), but somehow code running on the other core enabled the interrupt on this other core.

I haven't gotten to much deeper into this issue yet but appreciate the reply and help.
I found a Buffer issue I created by not protecting it with a mutex and having it being wrote and read by two threads. It was related to my Websocket usage which would cause my problem only when connected to WIFI so I hope fixing one fixed the other.
Since I couldn't produce the issue at will it is hard to see if that was the fix or not.