Open idobh2 opened 1 year ago
Seems like using taskENABLE_INTERRUPTS/taskDISABLE_INTERRUPTS is not a valid method on multi-core, see FreeRTOS documentation:
Warning Disabling interrupts is a valid method of achieve mutual exclusion in Vanilla FreeRTOS (and single core systems in general). However, in an SMP system, disabling interrupts is NOT a valid method ensuring mutual exclusion. Refer to Critical Sections for more details.
Seems like a change is needed to use taskENTER_CRITICAL(&spinlock)
/ taskEXIT_CRITICAL(&spinlock)
(or taskENTER_CRITICAL_ISR(&spinlock)
/ taskEXIT_CRITICAL_ISR(&spinlock)
from an interrupt context).
@idobh2 does your changes work for multiple setwatches too?
I'm seeing an issue with interrupts on ESP32, causing panic resets. My js code is pretty simple:
After a few log lines, I'm seeing the following error dumped
Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unhandled.
With some cpu register dump and then a reboot.After some digging, I'm pretty sure the cause to this error are the calls to
taskENABLE_INTERRUPTS()
andtaskDISABLE_INTERRUPTS();
injshInterruptOn
andjshInterruptOff
respectively, under the targets/esp32 implementaion.When I did the following (probably very irresponsible) change locally to the
targets/esp32/jshardware.c
, I stopped getting these panics, and interrupts worked wellFirst I defined a new global boolean
Then made sure the
gpio_intr_handler
doesn't push a new event ifintr_enabled
is false. this is done only after the interrupt is read and clearedThen I modified
jshInterruptOff
andjshInterruptOn
to changeintr_enabled
instead of callingtaskDISABLE_INTERRUPTS
/taskENABLE_INTERRUPTS
void jshInterruptOn() { //taskENABLE_INTERRUPTS(); intr_enabled = true; }