Crashes and libraries that use interrupts

[adrian-dybwad]

I wanted to let others know that if you use a library that uses interrupts, those interrupt events may cause your ESP to crash if you call WiFi or WiFiClient functions and an interrupt happens while the call is in progress.

I experienced this with the excellent SoftwareSerial port from here: https://github.com/plerup/espsoftwareserial.

The solution was to add functions to the library to disable the interrupts and then call that disable function before calling the WiFi and Client functions, then re-enable interrupts after.

Hope this helps some who may be experiencing crashes that may be hard to stop or explain!

[me-no-dev]

maybe if the library starts to use our attachInterrupt/detachInterrupt routines, then it might work.

[adrian-dybwad]

Thanks for the tip, I will look at that.

[igrr]

I have taken a look at this library and couldn't find any obvious reason why it would have to crash, especially during WiFi events. This needs some investigation, perhaps @plerup can give some pointers.

[kdsoo]

I'm having similar symptom not with some specific library but attachInterrupt().
First I suspected #797 issue but problem still remains after I change to staged branch.
Strange thing is when I get rid of whole code except attachinterrupt() and interrupt handler callback function, the problem disappears.
The extra code I get rid of is only about esp8266WebServer server(80)... server.handleClient() and EEPROM code which is only called on http request.
esp node crashes and reboot when external interrupt happens.
I attached PIR sensor on gpio 12 by the way. And it gives rising signal on presence detection.
esp node hangs exactly when signal rises and reboots after few secs.

[adrian-dybwad]

I had to disable the interrupts while processing WebServer requests too.

[plerup]

@adrionics What baud rate are you using?

[adrian-dybwad]

9600 or 2400, both have the problem.

[kdsoo]

I tried disabling interrupt while handling http request and enabling back afterward but still crashing.
I tried like follows..
......

const int PIR = 12;

void loop(void) {
disableInterrupt();
server.handleClient();
enableInterrupt();
}

void enableInterrupt() {
attachInterrupt(PIR, processPresence, RISING);
}

void disableInterrupt() {
detachInterrupt(PIR);
}

void processPresence() {
digitalWrite(13, 1);
}

....

[adrian-dybwad]

I fixed it by adding these two functions to the ESP SoftwareSerial library:
void SoftwareSerial::disable() {
ETS_GPIO_INTR_DISABLE();
}
void SoftwareSerial::enable() {
ETS_GPIO_INTR_ENABLE();
}

Then, call them before and after.

[kdsoo]

I found a glitch in my code. I forgot to comment out a single debugging message using softwareserial....
anyway it seems to be working fine with @adrionics 's workaround for now.
cheers!

[plerup]

If it helps just to disable the interrupts then there must be something triggering them when you get the crash. Maybe noise on the used rx pin.

As I stated in the comment in the source code the interrupt seems to trigger on any change on the pin although GPIO_PIN_INTR_NEGEDGE has been set.

I assume it's not real serial traffic in your case because then you would have missed it by disabling the interrupts.

[adrian-dybwad]

plerup, I suspect it may be noise or real serial traffic that triggers the crash - as you say, any change on the pin. I sometimes do miss serial packets while the interrupt is disabled, but luckily in my case this does not matter.

I believe that if an interrupt is triggered for any reason, and the device is in the process of handling some routine like WiFi.begin, it crashes.