Crash on Interrupt

[ssmith]

Been fighting a crash when trying to process an interrupt. It doesn't happen all the time but it is pretty consistent. My guess is it might be multiple ints causing a stack overflow or an int at the wrong time causing the same? I turn off the int first thing in the ISR though. Any ideas?

import machine
from machine import Pin
import time
from time import sleep
import binascii
import pycom
import gc
#import wifi

pycom.heartbeat(False)
version = "0.0.1"

""" Set wifi to On for debugging
    Set to Off for deployment
"""
wifi_mode = "Off"
def resume_handler(pin_obj):
   resume.callback(handler=None)
   global wifi_mode
   wifi_mode = "STATION_ON"

''' Pin 11 is used to turn on WiFi as station
'''
resume = Pin('P11',  mode=Pin.IN,  pull=Pin.PULL_UP)
resume.callback(trigger=Pin.IRQ_FALLING, handler=resume_handler)

sn = machine.unique_id()
sn = binascii.hexlify(sn)[-6:]
sn = sn.decode('utf8')
print("Serial Number:", sn)
print("SW Version:", version)

## Start Send
count = 0  # test count
retry = 0
payload = "SWVer: {}".format(version)
while True:
    gc.collect()
    payload = str(count)
    payload = "SN: {} -- MSG: {}  -- WiFi: {}".format(sn, count,  wifi_mode)

    print(" Payload_Test: {}".format(payload), "memfree: {}".format(gc.mem_free()))
    count += 1
    time.sleep(2)
 
    if wifi_mode == "STATION_ON":
        print("Station Int")
        wifi_mode = "Station"
        sleep(1)
        resume.callback(trigger=Pin.IRQ_FALLING, handler=resume_handler)```

Here's the crash dump

Running Int_Crash_test.py
Serial Number: 00832a
SW Version: 0.0.1
 Payload_Test: SN: 00832a -- MSG: 0  -- WiFi: Off memfree: 50464
 Payload_Test: SN: 00832a -- MSG: 1  -- WiFi: Off memfree: 50304
 Payload_Test: SN: 00832a -- MSG: 2  -- WiFi: Off memfree: 51984
 Payload_Test: SN: 00832a -- MSG: 3  -- WiFi: Off memfree: 51984
 Payload_Test: SN: 00832a -- MSG: 4  -- WiFi: Off memfree: 51968
 Payload_Test: SN: 00832a -- MSG: 5  -- WiFi: Off memfree: 52080
 Payload_Test: SN: 00832a -- MSG: 6  -- WiFi: Off memfree: 52144
 Payload_Test: SN: 00832a -- MSG: 7  -- WiFi: Off memfree: 52128
 Payload_Test: SN: 00832a -- MSG: 8  -- WiFi: Off memfree: 52128
 Payload_Test: SN: 00832a -- MSG: 9  -- WiFi: Off memfree: 52112
 Payload_Test: SN: 00832a -- MSG: 10  -- WiFi: Off memfree: 52144
 Payload_Test: SN: 00832a -- MSG: 11  -- WiFi: Off memfree: 52128
Station Int
 Payload_Test: SN: 00832a -- MSG: 12  -- WiFi: Station memfree: 52160
 Payload_Test: SN: 00832a -- MSG: 13  -- WiFi: Station memfree: 52144
 Payload_Test: SN: 00832a -- MSG: 14  -- WiFi: Station memfree: 52160
Station Int
 Payload_Test: SN: 00832a -- MSG: 15  -- WiFi: Station memfree: 52160
Guru Meditation Error of type LoadProhibited occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x400ec7d8  PS      : 0x00060730  A0      : 0x800eb248  A1      : 0x3ffe1f30  
A2      : 0x00000000  A3      : 0x00060723  A4      : 0x00060720  A5      : 0x3ffe1ed0  
A6      : 0x00000000  A7      : 0x3ffe1f10  A8      : 0x00000000  A9      : 0x00000001  
A10     : 0x3ffc3bbc  A11     : 0x00060723  A12     : 0x3ffe200c  A13     : 0x3ffe1fc0  
A14     : 0xffffff30  A15     : 0x3f40cd08  SAR     : 0x00000007  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  

Backtrace: 0x400ec7d8:0x3ffe1f30 0x400eb248:0x3ffe1f50 0x400eb29c:0x3ffe1f70 0x400dccac:0x3ffe1fa0 0x400e165a:0x3ffe1fc0 0x400d8238:0x3ffe2050

================= CORE DUMP START =================
CCkAAA0AAABsAQAA
cAv+P3Ae/j/cIP4/
YB/+P3Ag/j8AAAAArDr8P6w6/D9wC/4/pDr8Pw4AAAC8ePs/vHj7P3AL/j8AAAAA

[robert-hh]

@ssmith That's right. I recall that post. That is definitely an intentional behavior and looks like a Python bug. I have code for esp8266, which intensively modifies global variables, and that runs stable.
I had once ISRs, which modified global variables and after a while flagged, that it could not find that variable any more. As far as I recall, that was viper code on esp8266. So there might be similar strange conditions happen here.

[ssmith]

@robert-hh I think I fixed the issue. The clue was in this post: https://forum.pycom.io/topic/152/pin-interrupt-problem/3
It says you can't modify a global variable in an ISR so I made the ISR a class. Haven't seen it crash yet.

[robert-hh]

@ssmith One problem could be the bouncing of the switch. 1.6.12 was told to have some fixes on fast repetitive interrupts. I don'rt know if you are using it.

[ssmith]

@robert-hh
Same with these changes.

resume = Pin('P11',  mode=Pin.IN,  pull=Pin.PULL_UP)

def resume_handler(pin_obj,  resume=resume):
   resume.callback(handler=None)
   global wifi_mode
   wifi_mode = "STATION_ON"
resume.callback(trigger=Pin.IRQ_FALLING, handler=resume_handler)

[robert-hh]

@ssmith The interrupt handler does not know resume, and when it#s called and tries to print an error, it get's in trouble. Try re-ordering the lines. And yes. there may be trouble with multiple calls in a row.

''' Pin 11 is used to turn on WiFi as station
'''
resume = Pin('P11',  mode=Pin.IN,  pull=Pin.PULL_UP)
resume.callback(trigger=Pin.IRQ_FALLING, handler=resume_handler)

def resume_handler(pin_obj, resume=resume):
   resume.callback(handler=None)
   global wifi_mode
   wifi_mode = "STATION_ON"