attachInterrupt() occasionally causes crash

[Blake-James]

Board

ESP32-S3

Device Description

Custom PCB with ESP32-S3 WROOM

Hardware Configuration

GPIO 6 attached to interrupt output of an IMU

Version

v2.0.14

IDE Name

PlatformIO

Operating System

Windows

Flash frequency

240MHz

PSRAM enabled

yes

Upload speed

115200

Description

I've got a classic IoT device, waking up every xx minutes to record and upload sensor values before going back into deep sleep for a set amount of time. However there's also an IMU onboard with it's INT pin attached to GPIO 6 of the ESP32-S3 so that the ESP wakes immediately via interrupt if movement is detected.
This works fine 99% of the time but very occasionally the device will crash shortly after waking up from deep sleep at:

attachInterrupt(ImuInterrupt, ImuInterruptRoutine, RISING);

Sometimes it won't happen for a few days, and sometimes it'll happen multiple times in one day. Seems to be at random.
My interrupt routine is extremely minimal:

void IRAM_ATTR ImuInterruptRoutine() {
    // IMU interrupt routine for detecting vent events during runtime
    imuInterruptFlag = true;
    detachInterrupt(ImuInterrupt); // prevent routine from running again this wake cycle
}

My code already monitors available stack with uxTaskGetStackHighWaterMark(NULL), which shows no major reductions in available stack, usually sitting at around 29300 bytes. But I'm not sure if this correctly represents the available memory for IPC operations that's causing the crash?

Sketch

Every time it wakes from deep sleep it runs:
`pinMode(ImuInterrupt, INPUT);`
then:


void initOnboardDevices() {
    lg("i: SPL_init...");
    onboard_pressure_temp_device.SPL_init();
    lg("i: SPL_init complete");
    // initialise the imu so it can take accelerometer readings and will generate an interrupt if sufficiently tilted
    IMU_Onboard.begin();
    IMU_Onboard.Enable_X();
    IMU_Onboard.Disable_Wake_Up_Detection();
    IMU_Onboard.Disable_6D_Orientation();
    IMU_Onboard.Enable_6D_Orientation();
    lg("i: IMU init complete");
    attachInterrupt(ImuInterrupt, ImuInterruptRoutine, RISING);
    lg("i: IMU interrupt attached");
}

### Debug Message

```plain
stack:29300 heap:237556 time:988 i: SPL_init...
stack:29300 heap:237556 time:1039 i: SPL_init complete
stack:29300 heap:237556 time:1251 i: IMU init complete
Guru Meditation Error: Core  1 panic'ed (Unhandled debug exception). 
Debug exception reason: Stack canary watchpoint triggered (ipc1) 
Core  1 register dump:
PC      : 0x4038228b  PS      : 0x00060036  A0      : 0x80380bec  A1      : 0x3fcf1370  
A2      : 0x3fc992b0  A3      : 0xb33fffff  A4      : 0x0000cdcd  A5      : 0x00060023  
A6      : 0x00060023  A7      : 0x0000abab  A8      : 0xb33fffff  A9      : 0xffffffff  
A10     : 0x00000000  A11     : 0x3fc991f0  A12     : 0x7dd40000  A13     : 0x05120000  
A14     : 0x02c992b0  A15     : 0x00ffffff  SAR     : 0x0000000e  EXCCAUSE: 0x00000001  
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000  


Backtrace: 0x40382288:0x3fcf1370 0x40380be9:0x3fcf13b0 0x4037f23c:0x3fcf13e0 0x4037f232:0xa5a5a5a5 |<-CORRUPTED


ELF file SHA256: d804e1d1dc0d3f70

Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x40381f91  PS      : 0x00060034  A0      : 0x82057e04  A1      : 0x3fca16d0  
A2      : 0x3fca0ef4  A3      : 0x00000001  A4      : 0x3fcf10e0  A5      : 0x0000024c  
A6      : 0x00000008  A7      : 0x3fca18b4  A8      : 0x80381ff1  A9      : 0x3fca16b0  
A10     : 0x3fcf10e8  A11     : 0x3c10b573  A12     : 0x000000ff  A13     : 0x0000ff00  
A14     : 0x00ff0000  A15     : 0xff000000  SAR     : 0x00000020  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x0000000d  LBEG    : 0x400556d5  LEND    : 0x400556e5  LCOUNT  : 0xfffffffe  


Backtrace: 0x40381f8e:0x3fca16d0 0x42057e01:0x3fca1710 0x42058913:0x3fca1730 0x42058d28:0x3fca17c0 0x42057da5:0x3fca17f0


ELF file SHA256: d804e1d1dc0d3f70

Re-entered core dump! Exception happened during core dump!
Rebooting...

### Other Steps to Reproduce

_No response_

### I have checked existing issues, online documentation and the Troubleshooting Guide

- [X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[mathieucarbou]

Some notes:

void IRAM_ATTR ImuInterruptRoutine() {

IRAM_ATTR is useless: your code calls non-IRAM functions.

If you really need to stay in IRAM, you can see my library: https://github.com/mathieucarbou/MycilaPulseAnalyzer.
It contains an inlined version of gptimers allowing concurrent flash access with interrupts in Arduino, which is currently not possible.
(https://github.com/mathieucarbou/MycilaPulseAnalyzer/blob/main/src/inlined_gptimer.h).
You also need to set some build flags.

Debug exception reason: Stack canary watchpoint triggered (ipc1)

Not anough stack size allocated for ipc1

[Blake-James]

My understanding is that it's best practice to always include that IRAM_ATTR in all interrupt routine definitions. At least, it seems to appear in all the basic examples/tutorials that I see.
Perhaps the problem is that my project calls
attachInterrupt(ImuInterrupt, ImuInterruptRoutine, RISING);
again every time it wakes up from deep sleep? Should I be clearing the ISR function definition from IRAM each time before going to sleep?
In order to monitor this, how can I check the available IRAM memory available? My calls to uxTaskGetStackHighWaterMark(NULL), don't seem to suggest any memory leak.

[mathieucarbou]

It does not harm to have it, but it is useless since you call a non-iram function.

For Arduino, I would use instead ARDUINO_ISR_ATTR.

And only if you know what you are doing, then activate IRAM versions of them using (depending what you need):

  -D CONFIG_ARDUINO_ISR_IRAM=1
  -D CONFIG_GPTIMER_ISR_HANDLER_IN_IRAM=1
  -D CONFIG_GPTIMER_CTRL_FUNC_IN_IRAM=1
  -D CONFIG_GPTIMER_ISR_IRAM_SAFE=1
  -D CONFIG_GPIO_CTRL_FUNC_IN_IRAM=1

And even with that, some low level Arduino functions (and even som ESP-IDF ones) are not in IRAM or not always inlined, so they won't be in IRAM. So if you are doing concurrent flash access for example the board will crash.

Only use IRAM functions if you really know what you do and how to handle them correctly. In you case, it can very removed since you are calling detachInterrupt()

uxTaskGetStackHighWaterMark(NULL), don't seem to suggest any memory leak.

I would allocate more stack to the ipc1 task first, and then reduce it but by keeping some good amount 512-1k. That's what I use to do. I've setup a task which is periodically printing the HighWaterMark of the tasks I use for which I can control the stack size.

[553305][I][YASOLR][1][y-core] Free Heap: 111472
[553306][I][MONITOR][1][y-core] mqtt_task  (p=5) 2012 bytes
[553306][I][MONITOR][1][y-core] async_tcp  (p=10) 1380 bytes
[553317][I][MONITOR][1][y-core] y-pio      (p=1) 1208 bytes
[553332][I][MONITOR][1][y-core] y-core     (p=1) 712 bytes
[553332][I][MONITOR][1][y-core] y-mqtt     (p=1) 1132 bytes
[553343][I][MONITOR][1][y-core] y-router   (p=5) 920 bytes
[553343][I][MONITOR][1][y-core] y-jsy      (p=5) 1940 bytes
[553353][I][MONITOR][1][y-core] y-pzem     (p=5) 1432 bytes

[Jason2866]

Closing since outdated. feel free to ask to reopen if the issue still exists with actual Arduino