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

    Unhandled exception in interrupt handler

    Scheduled Pinned Locked Moved Issues & Bugs
    unhandled excepguru error
    23 Posts 5 Posters 9.5k Views 6 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.
    • L Offline
      livius @robert-hh
      last edited by

      @robert-hh
      can you show how that signals looks like
      maybe characteristic of raising and falling edge matters (how fast raise and how fast falling
      )
      or maybe @danielm have some noise in real signal?

      think about people first, then computers

      robert-hhR 1 Reply Last reply Reply Quote 0
      • robert-hhR Offline
        robert-hh @livius
        last edited by

        @livius If you scroll down and read in this post, you'll see the answers to your questions, and also has @daniel already expressed interest in this topic. For the last test I used the rise time seen bye @danielm.
        Using the pulse mode of my signal generator with transition times of about 7 ns the multiple interupts do not occur. B.T.W.: I had a similar effect on the ESP8266 with slow pulses. Very nasty!

        1 Reply Last reply Reply Quote 0
        • D Offline
          daniel
          last edited by

          @robert-hh thanks for the super detailed analysis! Can you share how did you solve this issue on the ESP8266?

          robert-hhR 1 Reply Last reply Reply Quote 0
          • robert-hhR Offline
            robert-hh @danielm
            last edited by

            @danielm @livius Until now I was testing with a symmetric triangle pulse of 50 µs duration. I switched now to a exp-rise pulse, with a rise time of ~25 µs. Funny enough, the double pulse disappeared, until I changed to trigger on the falling edge. I had made the same observation with other asymmetric pulses. The red trace is the input pulse for the green response. I cannot extend the pulse independently form the rise time without creating my own pulse shapes, which somehow fails with the vendors software (Windows only, with missing NI libs).
            0_1491899191521_exprise_100us.jpg

            1 Reply Last reply Reply Quote 0
            • robert-hhR Offline
              robert-hh @daniel
              last edited by

              @daniel Actually it were two different cases:
              a) Timer interrupt. If the handler took longer than about 500 µs, the handler seemed to be raised a second time. Solved by a flag in the handler, which checked whether it was already busy.
              b) External interrupt, which was called twice in a row. Solved by using a different drive with faster slopes..

              1 Reply Last reply Reply Quote 0
              • D Offline
                daniel
                last edited by

                @robert-hh thanks. Could the solution here be to disable GPIO interrupts while the C handler is executing (this is fast)?

                L 1 Reply Last reply Reply Quote 0
                • L Offline
                  livius @daniel
                  last edited by

                  @daniel
                  Then we can miss interrupt on different pin?
                  Or you mean interrupt on exact pin?

                  think about people first, then computers

                  1 Reply Last reply Reply Quote 0
                  • D Offline
                    daniel
                    last edited by

                    @livius I mean to disable the interrupt on that same pin.

                    L 1 Reply Last reply Reply Quote 0
                    • L Offline
                      livius @daniel
                      last edited by

                      @daniel
                      it looks like good concept - not overlapped events

                      think about people first, then computers

                      1 Reply Last reply Reply Quote 0
                      • D Offline
                        danielm
                        last edited by

                        I just want to remind that this issue remains unsolved on 1.6.13.b1

                        Counter 1: 10009 Counter 2: 6449 Counter 3: 12757
                        Counter 1: 10024 Counter 2: 6459 Counter 3: 12778
                        Counter 1: 10040 Counter 2: 6470 Counter 3: 12798
                        Counter 1: 10055 Counter 2: 6480 Counter 3: 12818
                        Counter 1: 10070 Counter 2: 6490 Counter 3: 12838
                        Counter 1: 10086 Counter 2: 6501 Counter 3: 12858
                        Counter 1: 10101 Counter 2: 6511 Counter 3: 12878
                        Counter 1: 10116 Counter 2: 6521 Counter 3: 12899
                        Counter 1: 10132 Counter 2: 6531 Counter 3: 12919
                        Counter 1: 10147 Counter 2: 6541 Counter 3: 12939
                        Guru Meditation Error of type InstrFetchProhibited occurred on core  0. Exception was unhandled.
                        Register dump:
                        PC      : 0xffffffff  PS      : 0x00060a30  A0      : 0x800eb2f0  A1      : 0x3ffe1f50
                        A2      : 0x3ffe28d0  A3      : 0x00000001  A4      : 0x00000000  A5      : 0x3ffe1f70
                        A6      : 0x00050823  A7      : 0x00000000  A8      : 0x800eb2ac  A9      : 0x3ffe1f30
                        A10     : 0x3ffe28d0  A11     : 0x00000001  A12     : 0x00000000  A13     : 0x3ffe1f70
                        A14     : 0x00000003  A15     : 0x00060823  SAR     : 0x00000012  EXCCAUSE: 0x00000014
                        EXCVADDR: 0xfffffffc  LBEG    : 0x400f753a  LEND    : 0x400f7543  LCOUNT  : 0x00000000
                        
                        Backtrace: 0x7fffffff:0x3ffe1f50 0x400eb2f0:0x3ffe1f70 0x400dccb8:0x3ffe1fa0 0x400e1672:0x3ffe1fc0 0x400d8244:0x3ffe2050
                        
                        ================= CORE DUMP START =================
                        
                        ...
                        
                        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
                        • 2
                        • 2 / 2
                        • First post
                          Last post

                        Pycom on Twitter

                        Pycom