Conflicting Deep Sleep Info

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

cross mob
Anonymous
Not applicable

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!

0 Likes
1 Solution
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

View solution in original post

0 Likes
17 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
Anonymous
Not applicable

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?

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

   

Did I post something different?

   

 

   

Bob

0 Likes
Anonymous
Not applicable

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!

0 Likes
Anonymous
Not applicable

|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?

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
Anonymous
Not applicable

Thanks for the clarification, much appreciated!

   

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

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
Anonymous
Not applicable

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.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
Anonymous
Not applicable

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!

0 Likes
Anonymous
Not applicable

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!

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
Anonymous
Not applicable

Jason T, Bob Marlowe: You refer to this application note: http://www.cypress.com/file/121271/download . This is for PSoC4, without BLE in its name. How does PSoC4 and PSoC4BLE relate? Are PSoC4BLE pretty the same as PSoC4, just with BLE in addition? Or should I only use the information (like application notes) given for the PSoC4BLE for development?

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

PSoC is a basic concept: A CPU with flash and sram, a bunch of adaptable components, pins and routing. The difference between the PSoC families (PSoC1, 3, 4 and 5) define which kind of CPU is used, the different devices within a family indicate the amount of resources (flash, ram, components). BLE is based on a PSoC4 as the PRoC is, so most of the specifications apply to all of them. Differences are found in the clock distribution of BLE. and for PRoC the absence of most components except for a very few communication interfaces.

   

should I only use the information (like application notes) given for the PSoC4BLE for development? AC and DC specifications, pinouts etc are of course to be taken from the chip-specific TRM. Components and component behavior are written down in the component's datasheet. Sou you may use appnotes with examples for PSoC4 and use them on a PSoC4 BLE. You might run out of resources, but that you will see on an early state of the project.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Thank you. Good to know that PSoC4 info can be used for PSoC4BLE.

0 Likes