Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    Crash on Interrupt

    Scheduled Pinned Locked Moved LoPy
    crashinterrupt
    6 Posts 2 Posters 1.9k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S Offline
      ssmith
      last edited by

      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-hhR 1 Reply Last reply Reply Quote 0
      • robert-hhR Offline
        robert-hh @ssmith
        last edited by

        @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"
        
        S 1 Reply Last reply Reply Quote 0
        • S Offline
          ssmith @robert-hh
          last edited by

          @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-hhR 1 Reply Last reply Reply Quote 0
          • robert-hhR Offline
            robert-hh @ssmith
            last edited by

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

            S 1 Reply Last reply Reply Quote 0
            • S Offline
              ssmith @robert-hh
              last edited by

              @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-hhR 1 Reply Last reply Reply Quote 0
              • robert-hhR Offline
                robert-hh @ssmith
                last edited by

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

                1 Reply Last reply Reply Quote 0

                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
                • 1 / 1
                • First post
                  Last post

                Pycom on Twitter

                Pycom