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 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" -
@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 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 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 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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login