- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I have run into a problem. I find that after calling CySysPmDeepSleep(), I am unable to _Start a component that I stopped prior to going to sleep. I do not experience this problem is I _Sleep() and than _Wakeup() the component, or if I CySysPmSleep() instead of using DeepSleep.
I have attached a project that demonstrates this issue. It can be tested directly against the PRoC or PSoC on the CY8CKIT-042-BLE test kit, or with some minor changes, on the regular PSoC 4. This problem does not exist on the regular PSoC 4.
In a nut shell, here is the problem:
/* Prepare for sleep */
PWM_Sleep(); // Sleeping the PWM works
//PWM_Stop(); // Stopping the PWM causes it to not be restartable after Deep Sleep
/* Go into deep sleep */
//CySysPmSleep(); // Both Stop/Start and Sleep/Wakeup work after a standard sleep
CySysPmDeepSleep(); // Only Sleep/Wakeup works after a deep sleep
/* Wake up */
PWM_Wakeup(); // Waking up the PWM after sleep works
//PWM_Start(); // Starting the PWM after sleep does not work after Deep Sleep
Any thoughts would be appreciated. If there is a piece of documentation describing this behavior I am missing, I would appreciate that being pointed out to me as well. I've been unable to locate anything.
Thank you.
- Chris
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You have seen these -
http://www.cypress.com/?rID=78797 AN86233 - PSoC® 4 Low-Power Modes and Power Reduction Techniques
http://www.cypress.com/?rID=110007 AN92584 - Designing for Low Power and Estimating Battery Life for BLE
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think that the error is connected to send a component to sleep and then applying an API other than Wakeup(). Did you try to use
PWM_Stop();
PWM_Sleep();
CySysPmDeepSleep();
PWM_Wakeup();
PWM_Start();
which seems to me to be a more logical sequence.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
According to AN82833 looks like PWM does NOT have to be restarted -
Its in retention mode if UDB. The only thing I noticed is IMO gets disabled,
clue that PWM clock may need to be restarted ? Not sure.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
The following works, but it essentially the same thing as using _Sleep() and _Wakeup()
PWM_SaveConfig();
PWM_Stop();
CySysPmDeepSleep();
PWM_RestoreConfig();
PWM_Start();
I am trying to avoid saving the state as I do not need to and it adds about 300 bytes to the final executable. This problem does not exist on the regular PSoC 4.
Thanks for your suggestion.
- Chris
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, why don't you leave out the saving and restoring of the configuration and simply issue a _Stop(), CyPmDeepSleep() and a _Start() for your PWM. As Dana showed in the table all necessary settings are retained during deep-sleep and for the PSoC4 the clocks do not have to be restarted manualy.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
At issue is the fact that _Stop() and _Start() do not work if the device enters deep sleep between the two calls.
Works just fine:
PWM_Sleep();
CySysPmDeepSleep();
PWM_Wakeup();
Works just fine:
PWM_Stop();
PWM_SaveConfig();
CySysPmDeepSleep();
PWM_RestoreConfig();
PWM_Start();
Works just fine:
PWM_Stop();
CySysPmSleep();
PWM_Start();
Does NOT work:
PWM_Stop();
CySysPmDeepSleep();
PWM_Start();
- Chris
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the testing, I learned as well.
Looks like not just the main clocks but all user clocks also get restarted w/o
user intervention.
Regards, Dana.