Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Troubleshooting
  3. [SOLVED] latest git-snapshot causes freezes

[SOLVED] latest git-snapshot causes freezes

Scheduled Pinned Locked Moved Troubleshooting
46 Posts 6 Posters 9.7k Views 5 Watching
  • 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.
  • cimba007C Offline
    cimba007C Offline
    cimba007
    wrote on last edited by cimba007
    #36

    Jep, this is the library.

    https://github.com/mysensors/MySensors/blob/development/core/MyHwATMega328.cpp#L86
    https://github.com/mysensors/MySensors/blob/master/core/MyHwATMega328.cpp#L75

    well .. I have no idea but on my code it is there:

    0_1475516793275_upload-115e8437-9933-4d71-ba85-0f3f11ea7036

    Seems to be neither in the stable nor the developement branch .. but I most gotten it somewhere .. lets check

    I think I added it for some reason on latest stable. Otherwise pinchage-interrupt was not working with mysensors-library .. I will try to remove it on stable to see if I get stuck there too and add in snapshot to see if it helps in some way.

    EDIT1: Adding in the latest snapshot doesn't change a thing
    EDIT2: Removing it in the latest stable doesn't change a thing

    I might have added it from another testsketch .. but it would be better located in that sketch right after the sleep function .. so just ignore it for now - my bad ;_(

    YveauxY 1 Reply Last reply
    0
    • cimba007C cimba007

      Jep, this is the library.

      https://github.com/mysensors/MySensors/blob/development/core/MyHwATMega328.cpp#L86
      https://github.com/mysensors/MySensors/blob/master/core/MyHwATMega328.cpp#L75

      well .. I have no idea but on my code it is there:

      0_1475516793275_upload-115e8437-9933-4d71-ba85-0f3f11ea7036

      Seems to be neither in the stable nor the developement branch .. but I most gotten it somewhere .. lets check

      I think I added it for some reason on latest stable. Otherwise pinchage-interrupt was not working with mysensors-library .. I will try to remove it on stable to see if I get stuck there too and add in snapshot to see if it helps in some way.

      EDIT1: Adding in the latest snapshot doesn't change a thing
      EDIT2: Removing it in the latest stable doesn't change a thing

      I might have added it from another testsketch .. but it would be better located in that sketch right after the sleep function .. so just ignore it for now - my bad ;_(

      YveauxY Offline
      YveauxY Offline
      Yveaux
      Mod
      wrote on last edited by
      #37

      @cimba007 Well, I filed (https://github.com/mysensors/MySensors/issues/598) and fixed (https://github.com/mysensors/MySensors/pull/599) and issue with interrupts not being detached correctly in all cases when using hwSleep().
      This might be causing your issue, but is hard to say without actually debugging the code.
      Once the PR is merged, could you try getting the latest development branch and see if it fixes the issue? (please use the development branch, without any local modifications)

      http://yveaux.blogspot.nl

      1 Reply Last reply
      1
      • cimba007C Offline
        cimba007C Offline
        cimba007
        wrote on last edited by cimba007
        #38

        Just copy'pasted your fix and .. voila

        Problems seems to be solved - although I do not unterstand why?!

        • _wakeUp2Interrupt should be totally unrelated as it is never set
        • detach should happen in the ISR

        .. even if the interrupt is not detached correctly .. how should it lead to the total skip of these code:

        	cli();
        	wdt_reset();
        	// enable WDT changes
        	WDTCSR |= (1 << WDCE) | (1 << WDE);
        	// restore saved WDT settings
        	WDTCSR = WDTsave;
        	Serial.println("sei()");
        	Serial.flush();
        	sei();
        	// enable ADC
        	ADCSRA |= (1 << ADEN);
        	//WDTCSR |= (1 << WDIE); // set the WDIE flag to enable interrupt callback function.
        

        As this code-snipped is skipped sei() gets never called in my case .. and the subsequent call to i2c freezes the node ... as i2c depends on interrupts ..

        Anyway thanks Yveaux .. althour your fix is simple .. i don't know why it is working ...

        EDIT: Furthermore .. even if the interrupt is not detached in the isr .. there should be no further interrupt if the interrupt register is not read via i2c .. and that in fact doesn't happen >:>

        YveauxY 1 Reply Last reply
        0
        • cimba007C cimba007

          Just copy'pasted your fix and .. voila

          Problems seems to be solved - although I do not unterstand why?!

          • _wakeUp2Interrupt should be totally unrelated as it is never set
          • detach should happen in the ISR

          .. even if the interrupt is not detached correctly .. how should it lead to the total skip of these code:

          	cli();
          	wdt_reset();
          	// enable WDT changes
          	WDTCSR |= (1 << WDCE) | (1 << WDE);
          	// restore saved WDT settings
          	WDTCSR = WDTsave;
          	Serial.println("sei()");
          	Serial.flush();
          	sei();
          	// enable ADC
          	ADCSRA |= (1 << ADEN);
          	//WDTCSR |= (1 << WDIE); // set the WDIE flag to enable interrupt callback function.
          

          As this code-snipped is skipped sei() gets never called in my case .. and the subsequent call to i2c freezes the node ... as i2c depends on interrupts ..

          Anyway thanks Yveaux .. althour your fix is simple .. i don't know why it is working ...

          EDIT: Furthermore .. even if the interrupt is not detached in the isr .. there should be no further interrupt if the interrupt register is not read via i2c .. and that in fact doesn't happen >:>

          YveauxY Offline
          YveauxY Offline
          Yveaux
          Mod
          wrote on last edited by
          #39

          @cimba007 Great to hear it solves your problem!

          Regarding the serial print not showing: you call it from withing a section with interrupts disabled; I don't know if this will work at all, or maybe even cause a hang... I would toggle some IO pins instead and use an oscilloscope to verify program flow.

          Sleeping an AVR using the watchdog and pin interrupts is some tricky stuff, which is very susceptible to race conditions and almost impossible to debug without a decent hardware debugger.
          Having a compiler that woes every now and then also isn't helping...

          http://yveaux.blogspot.nl

          1 Reply Last reply
          1
          • cimba007C Offline
            cimba007C Offline
            cimba007
            wrote on last edited by
            #40

            I only used the pin change interrupt in another sketch. I was doubting Serial in sections without isr too! But they are clever. Serial output depends on polling in sections where interrupts are disabled ;-)

            YveauxY 1 Reply Last reply
            0
            • cimba007C cimba007

              I only used the pin change interrupt in another sketch. I was doubting Serial in sections without isr too! But they are clever. Serial output depends on polling in sections where interrupts are disabled ;-)

              YveauxY Offline
              YveauxY Offline
              Yveaux
              Mod
              wrote on last edited by
              #41

              @cimba007 said:

              Serial output depends on polling in sections where interrupts are disabled

              Ok, learned something today ;-)

              The PR has now been merged to development btw.

              http://yveaux.blogspot.nl

              cimba007C chrilleC 2 Replies Last reply
              0
              • YveauxY Yveaux

                @cimba007 said:

                Serial output depends on polling in sections where interrupts are disabled

                Ok, learned something today ;-)

                The PR has now been merged to development btw.

                cimba007C Offline
                cimba007C Offline
                cimba007
                wrote on last edited by cimba007
                #42

                @Yveaux While we are at this topic .. any chance to let the user-code know what caused the wakeup during sleep() ??

                For example .. if there was a wakeup at all or which of the two interrupt sources was the cause.

                Unforunatly the "cause" gets cleaned up at the end of hwSleep:

                bool interruptWakeUp()
                {
                    return _wokeUpByInterrupt != INVALID_INTERRUPT_NUM;
                }
                

                Calling this from user-code will always return 0 as the end of hwSleep does this:

                 _wokeUpByInterrupt = INVALID_INTERRUPT_NUM;
                

                Not clearing the "last interrupt source" would be nice.

                tekkaT 1 Reply Last reply
                0
                • cimba007C cimba007

                  @Yveaux While we are at this topic .. any chance to let the user-code know what caused the wakeup during sleep() ??

                  For example .. if there was a wakeup at all or which of the two interrupt sources was the cause.

                  Unforunatly the "cause" gets cleaned up at the end of hwSleep:

                  bool interruptWakeUp()
                  {
                      return _wokeUpByInterrupt != INVALID_INTERRUPT_NUM;
                  }
                  

                  Calling this from user-code will always return 0 as the end of hwSleep does this:

                   _wokeUpByInterrupt = INVALID_INTERRUPT_NUM;
                  

                  Not clearing the "last interrupt source" would be nice.

                  tekkaT Offline
                  tekkaT Offline
                  tekka
                  Admin
                  wrote on last edited by
                  #43

                  @cimba007 The return value of sleep() indicates the wake-up cause: irq (nr) or timer (=MY_WAKE_UP_BY_TIMER).
                  See here: https://github.com/mysensors/MySensors/blob/development/core/MyHwATMega328.cpp#L146-L147

                  cimba007C 1 Reply Last reply
                  0
                  • ikkeTI Offline
                    ikkeTI Offline
                    ikkeT
                    wrote on last edited by
                    #44

                    I also confirm it fixed my problem. Thank you!

                    1 Reply Last reply
                    1
                    • tekkaT tekka

                      @cimba007 The return value of sleep() indicates the wake-up cause: irq (nr) or timer (=MY_WAKE_UP_BY_TIMER).
                      See here: https://github.com/mysensors/MySensors/blob/development/core/MyHwATMega328.cpp#L146-L147

                      cimba007C Offline
                      cimba007C Offline
                      cimba007
                      wrote on last edited by
                      #45

                      @tekka Thanks, that is what I was looking for

                      1 Reply Last reply
                      0
                      • YveauxY Yveaux

                        @cimba007 said:

                        Serial output depends on polling in sections where interrupts are disabled

                        Ok, learned something today ;-)

                        The PR has now been merged to development btw.

                        chrilleC Offline
                        chrilleC Offline
                        chrille
                        wrote on last edited by
                        #46

                        @Yveaux Thank you for committing this fix. I had the same issue and it caused me a lot of headache

                        1 Reply Last reply
                        0
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        24

                        Online

                        11.7k

                        Users

                        11.2k

                        Topics

                        113.1k

                        Posts


                        Copyright 2025 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • MySensors
                        • OpenHardware.io
                        • Categories
                        • Recent
                        • Tags
                        • Popular