Crash on Interrupt



  • 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
    


  • @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.



  • @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.



  • @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.



  • @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)
    
    


  • @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"
    

Log in to reply
 

Pycom on Twitter