GPIO Interrupt without the ECO

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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?

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
AnjanaM_61
Moderator
Moderator
Moderator
5 comments on KBA First comment on KBA 5 questions asked

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

   

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

View solution in original post

0 Likes
10 Replies
Anonymous
Not applicable

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);

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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 🙂

0 Likes
Anonymous
Not applicable

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();
    }
}

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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

0 Likes
lock attach
Attachments are accessible only for community members.
AnjanaM_61
Moderator
Moderator
Moderator
5 comments on KBA First comment on KBA 5 questions asked

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

   

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

0 Likes
Anonymous
Not applicable

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?

0 Likes