1 2 Previous Next 16 Replies Latest reply on Mar 22, 2016 8:43 AM by cjoachim_1597296

    Conflicting Deep Sleep Info

    jason.thibado

      In my application, I am sampling an accelerometer at 1600 Hz. In my ISR, I set a flag which is then processed in my main loop. This works fine when I don't use any sleep modes.

         

       

         

      However, once I add CySysPmDeepSleep() into the main loop, I never wake up and service the interrupt. I service the interrupt once before going to sleep, but never wake back up to service it again.

         

      According to this document, a GPIO interrupt is a valid wakeup source from deep sleep:

         

      http://www.cypress.com/file/121271/download

         

       

         

      In another document, it states that all GPIO are frozen automatically when entering deep sleep (section 10.12):

         

       

         

      http://www.cypress.com/file/127101/download

         

      The behavior I'm seeing implies the latter is correct, since it seems like the GPIO tied to my accelerometer is no longer causing me to wake from deep sleep. I only have this problem with deep sleep as CySysPmSleep() works without issue and I see my accel interrupt at 1600 Hz.

         

       

         

      Am I misinterpreting one of these app notes, because they seem to have conflicting information? Any help is greatly appreciated!

        • 1. Re: Conflicting Deep Sleep Info
          user_1377889

          A "Frozen" GPIO maintains its current output state, pin interrupts are used for GPIO inputs. There can be the case where the frozen iotput state does not allow a level change as seen by the interrupt circuits.

             

          Do not use an isr component, the pin interrupt is handled by the PICU.

             

          Keep in mind that waking up from deep sleep takes something like 12 to 25ms which will not fit with your sample rate of 1600sps.

             

           

             

          Bob

          • 2. Re: Conflicting Deep Sleep Info
            jason.thibado

            Hi Bob,

               

             

               

            Thanks for the reply, according to this docuement:

               

             

               

            http://www.cypress.com/file/121271/download

               

            (Section 2 Power Mode Summary)

               

            The PSoC can wake up from deep sleep in 25 us. Is this not the case?

            • 3. Re: Conflicting Deep Sleep Info
              user_1377889

              The PSoC can wake up from deep sleep in 25 us. Is this not the case?

                 

              Did I post something different?

                 

               

                 

              Bob

              • 4. Re: Conflicting Deep Sleep Info
                jason.thibado

                Bob,

                   

                Yes, your earlier post states:

                   

                | Keep in mind that waking up from deep sleep takes something like 12 to 25ms which will not fit with your sample rate of 1600sps

                   

                I agree with your original assessment that wakeup of 25ms is too long for an ODR of 1600 Hz, but 25 us should not be a problem. Can you confirm it is indeed 25 us as per the document and NOT 25 ms as per your post?

                   

                 

                   

                Thanks for your help!

                • 5. Re: Conflicting Deep Sleep Info
                  jason.thibado

                  |Do not use an isr component, the pin interrupt is handled by the PICU

                     

                  Do you mean this can be done without an ISR component which would eliminate the issue of frozen GPIO?

                  • 6. Re: Conflicting Deep Sleep Info
                    user_1377889

                    25µs is correct, sorry.

                       

                    Do you mean this can be done without an ISR component which would eliminate the issue of frozen GPIO?

                       

                    Yes, without an isr component. But that alone will not prevent a frozen pin. You may of course re-program the pin to hi-z imput before sleeping and set it back to original mode when waken up.

                       

                     

                       

                    Bob

                    • 7. Re: Conflicting Deep Sleep Info
                      jason.thibado

                      Thanks for the clarification, much appreciated!

                         

                      So is there no way to use a GPIO interrupt from an accelerometer to wake from deep sleep?

                      • 8. Re: Conflicting Deep Sleep Info
                        user_1377889

                        So is there no way to use a GPIO interrupt from an accelerometer to wake from deep sleep?

                           

                        Of course, use a pin as input pin, set pin properties as interrupt on your desired edge. After waking up clear the pin's interrupt.

                           

                         

                           

                        Bob

                        • 9. Re: Conflicting Deep Sleep Info
                          jason.thibado

                          Well, that is what I've been attempting to do. I am using a GPIO rising edge interrupt to wake from deep sleep. The problem is the interrupt is firing, but I do not wake from deep sleep.

                             

                          If I simply use sleep, or no low power mode at all, I don't have issues. The problem only arises with deep sleep.

                          • 10. Re: Conflicting Deep Sleep Info
                            user_1377889

                            Can you post your complete project, so that we all can have a look at all of your settings? To do so, use
                            Creator->File->Create Workspace Bundle (minimal)
                            and attach the resulting file.

                               

                             

                               

                            Bob

                            • 11. Re: Conflicting Deep Sleep Info
                              user_1377889

                              Excerpt from pin datasheet. Page 17

                                 

                              Dedicated Interrupt
                              Ports on certain devices do not have dedicated Port Interrupts capable of waking up the chip from deep-sleep. They can all however provide port-wide wakeup from chip sleep mode. Check the Dedicated Interrupt check box to be able to use the port dedicated interrupt logic, if you do not intend to use it for wakeup from deep-sleep mode.
                              If however you do wish to use the pin as a wakeup source from chip deep-sleep, then refer to the TRM to see if that particular port has the capability of waking up the device from chip deep-sleep.

                                 

                              I read that as it has to be disabled.

                                 

                              Moreover Sync Mode:

                                 

                              I would suggest to choose "transparent", because there is no high frequency clock in deep sleep.

                                 

                              The isr component is not needed for recovering from deep sleep.

                                 

                               

                                 

                              Bob

                              • 12. Re: Conflicting Deep Sleep Info
                                jason.thibado

                                Thanks Bob. According the TRM, all PSoC 4100/4200 GPIO can be used as an interrupt to wake from deepsleep, so I think I'm ok on that front.

                                   

                                 

                                   

                                I disabled the 'dedicated interrupt' option and also switched to transparent. I configured the GPIO as a rising edge interrupt in firmware as follows:

                                   

                                 

                                   

                                uint32 regVal = 0x00u;
                                regVal = CY_GET_REG32(HIGHG_INT1_IN__INTCFG);
                                regVal &= ~(INTERRUPT_MASK << (HIGHG_INT1_IN_SHIFT * 2));
                                CY_SET_REG32(HIGHG_INT1_IN__INTCFG, regVal | (RISING_EDGE << (HIGHG_INT1_IN_SHIFT * 2)));

                                   

                                Again, this works if I don't use deep sleep. As soon as I add that call back in, I never wake up even though the interrupt line went high.

                                   

                                 

                                   

                                Regarding the isr component, is there any downside to using it? Does it have to be removed?

                                   

                                 

                                   

                                Thanks!

                                • 13. Re: Conflicting Deep Sleep Info
                                  jason.thibado

                                  Bob,

                                     

                                  Okay, I think I got it working! I followed the section PSoC 4 dedicated port interrupts in the pin datasheet and added the AllPortInt signal and an associated interrupt component. In the ISR, I check for my pins interrupt and clear it.

                                     

                                   

                                     

                                  Seems to be working, but I'll continue testing and ensure I see the current draw I expect. Thank you for getting me pointed in the right direction!

                                  • 14. Re: Conflicting Deep Sleep Info
                                    user_1377889

                                    Awesome! Do not forget to disable debugging (by setting the pins to GPIO) when performing current measurements. Debugging costs some mA.

                                       

                                    uint32 regVal = 0x00u;
                                    regVal = CY_GET_REG32(HIGHG_INT1_IN__INTCFG);
                                    regVal &= ~(INTERRUPT_MASK << (HIGHG_INT1_IN_SHIFT * 2));
                                    CY_SET_REG32(HIGHG_INT1_IN__INTCFG, regVal | (RISING_EDGE << (HIGHG_INT1_IN_SHIFT * 2)));

                                       

                                    Sorry, I cannot follow that cryptic assignments at all. Why don't you use the configuration dialogs and the APIs? That is usually quite less error prone than hand made bit banging.

                                       

                                     

                                       

                                    Bob

                                    1 2 Previous Next