10 Replies Latest reply on Jul 3, 2017 12:59 AM by anpm

    GPIO Interrupt without the ECO

    gyurko_1700226

      I'm using a PROC-BLE module and am finding that if I disable the ECO before going to deep sleep, that my external interrupt doesn't wake the CPU.  It does work if I don't disable the ECO, but that's using too much power.

         

      Any suggestions?

        • 1. Re: GPIO Interrupt without the ECO
          e.pratt_1639216

          The example code I've found that works well changes the ECO to be the HFCLK and disables the IMO clock to reduce power. Obviously, this will affect peripherals, but I've found it works if you are waiting for GPIO interrupts.

             

          Here is the snippet that is relevant:

             

          intrStatus = CyEnterCriticalSection();
                  blessState = CyBle_GetBleSsState();
                  if((blessState == CYBLE_BLESS_STATE_ECO_ON ||
                  blessState == CYBLE_BLESS_STATE_DEEPSLEEP)) {
                      CySysPmDeepSleep();
                  } else if(blessState != CYBLE_BLESS_STATE_EVENT_CLOSE) {
                      CySysClkWriteHfclkDirect(CY_SYS_CLK_HFCLK_ECO);
                      CySysClkImoStop();
                      CySysPmSleep();
                      CySysClkImoStart();
                      CySysClkWriteHfclkDirect(CY_SYS_CLK_HFCLK_IMO);
                  }
                  CyExitCriticalSection(intrStatus);

          • 2. Re: GPIO Interrupt without the ECO
            gyurko_1700226

            What I found is that it's not dependent on the clock while in deepsleep, it doesn't work if the CPU is running from IMO or ECO.  It's the deepsleep that's the problem.  The GPIO interrrupt isn't waking up the CPU from deepsleep.  In your example, you go to sleep mode.  If I do that instead of deepsleep, my interrupt works.

            • 3. Re: GPIO Interrupt without the ECO
              gyurko_1700226

              I need to be running in the uA range and sleep only get's me down to the couple of mA range.

              • 4. Re: GPIO Interrupt without the ECO
                e.pratt_1639216

                I've had it working in deep-sleep mode for interrupt wakeup on port change; The example above just optimizes to sleep instead if it is unable to go to deep sleep due to peripherals running.

                   

                I setup three contiguous pins on port 1 (pins 4,5,6) to be Resistive Pull Up, Initial Drive State High, Digital Input, CMOS, Both Edges Dedicated Interrupt, Transparent, Input Buffer Enabled. So far, it has been working for triggering wakeup on both rising/falling edges, but it could entirely be that it is only firing when falling edges occur, and the buttons are merely bouncing enough to trigger on both mechanical edges.

                   

                We also know it is really going into deepsleep, as we ran a current measurement on it to make sure the device was drawing the correct range of power usage for operation.

                   

                Also, depending on how you are wiring your clocking under "Clocks->Configure System Clocks" it could be that you are routing the ECO to other clocks, and thus turning off the ECO is crashing things.

                   

                Double check that your cap trim values are correct on th ECO while you are looking into things too :)

                • 5. Re: GPIO Interrupt without the ECO
                  gyurko_1700226

                  Thanks for the feedback.  I created a new project with just the following code to minimize the possible sources of the problem.  With the following code, I have an input configured to interrupt on falling edge, and have the pin configured with a pullup.  There's also a pin configured as an output and I toggle its state in the ISR...watching it on a scope.

                     

                  With the following code, the output toggles each time I ground the input which shows me the ISR is working as expected.

                     

                  However, if I change the CySysPmSleep() to CySysPmDeepSleep(), it stops working.  It's not waking from deep sleep.

                     

                  I originally thought it was related to the ECO, but I can confirm it doesn't matter if the ECO is running or not.

                     

                  I may repost the issue with a different title now that I know what the real problem is.

                     

                   

                     

                   

                     

                  CY_ISR(wakeup_isr)
                  {
                      if(out_on == 0)
                      {
                          OutPin_Write(1);
                          out_on = 1;
                      }
                      else
                      {
                          OutPin_Write(0);
                          out_on = 0;
                      }
                      isr_1_ClearPending();
                  }

                     

                  int main()
                  {
                      OutPin_Write(0);
                      isr_1_StartEx(&wakeup_isr);
                   
                      CyGlobalIntEnable;

                     

                      for(;;)
                      {
                          CySysPmDeepSleep();
                      }
                  }

                  • 6. Re: GPIO Interrupt without the ECO
                    e.pratt_1639216

                    I would make a few changes to the code to ensure it isn't a software issue rather than the edge-trigger being the issue while in deep-sleep:

                       

                    int main()
                    {
                        OutPin_Write(0);
                        isr_1_StartEx(&wakeup_isr);
                     
                        CyGlobalIntEnable;

                       

                        for(;;)
                        {

                       

                            DebugPin_Write(0);
                            CySysPmDeepSleep();

                       

                            DebugPin_Write(1);

                       

                            CySysDelay(1000);
                        }
                    }

                       

                     

                       

                    That way, you are verifying the deep-sleep is being interrupted/woken from upon pin toggling, and it is instead an issue with software (which is easy to fix) debouncing, or timing.

                    • 7. Re: GPIO Interrupt without the ECO
                      gyurko_1700226

                      It turned out to be that you need to use a Global Signal Reference as the source of the wakeup ISR.  The pin interrupt will not wake from deep sleep.

                         

                      http://www.cypress.com/forum/proc-ble/gpio-interrupt-without-eco

                      • 8. Re: GPIO Interrupt without the ECO
                        e.pratt_1639216

                        Ah, I forgot about that detail. Good job finding it! I'll have to be more mindful of it in the future.

                        • 9. Re: GPIO Interrupt without the ECO
                          anpm

                          Hi,

                             

                          Please note there is a contradiction to the post #8.

                             

                          The device do wake up from deep sleep for a GPIO interrupt. You can refer the appnote for details : http://www.cypress.com/documentation/application-notes/an92584-designing-low-power-and-estimating-battery-life-ble

                             

                          Please make sure your pin interrupt settings are correct. For the cy_isr component connected to the GPIO interrupt pin, make sure the InterruptType is DERIVED as in attached screenshot. Else it won't trigger the device to wake up from deepsleep.

                             

                          Regards,
                          Anjana

                          • 10. Re: GPIO Interrupt without the ECO
                            e.pratt_1639216

                            Hmmm, I can't remember exactly, but there was a reason I used the gobal signal reference in my design...

                               

                            I think I wanted edge-triggered interrupts instead of level, as the level-detect was causing active-low buttons to fire continuously?