This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
Could TI recommend a type of external circuit/device to drive DEEPSLEEP low in the process of turning OMAP L138 into deep sleep mode?
In “10.10.1 Entering Deep Sleep Mode” of L138 TRM, although for waking the chip up from deep sleep one can both use an external signal or RTC, for putting the device INTO deep sleep however one must uses an external signal to drive DEEPSLEEP low to complete the final step.
Which circuit/device should be used to do this final step?
One option I know is to use a cheap MSP430, and its internal timer could guarantee sufficient delay so that it could work in conjunction with L138 to put L138 into deepsleep.
Another option might be use some circuit combination, for example a MOSFET with some other component, to somehow create a delay before it starts putting DEEPSLEEP pin low.
Since MSP430 chips are very cheap and its performance is guaranteed, it seems more attractive than using circuit solution since the later requires accurate calculation, among other considerations.
We would like to know which method, or a better one, does TI recommend?
Paul
Paul,
An MSP430 based solution would be a good option. If you are looking at ready to go solution for designing low power solutions on Freon, Logic PD provides a Wattson board for power monitoring on OMAPL138 that should have this functionality.
I have provided a link to this
http://createnewstuff.webs.com/breakoutboardwattson.htm
You might want to confirm with Logic PD sales person that their software and circuit can support all your required scenerios. I am also not aware of the cost involved so this might also be something that you can check with them.
Regards,
Rahul
Rahul,
I am aware of the Wattson solution; meanwhile I am also able to monitor board currents using current sensing IC's on my customized board. Our solution is very similar to Wattson so we are good on this aspect.
Regarding your comment on MSP430,
1. L138 TRM (and sprugm7) section 10.10.2 contains steps for putting the device into DEEP SLEEP mode without using external circuit. Have you or your colleague tested that (I will do that shortly after some other problems got solved)?
2. Since 10.10.2 says the device can put itself into DEEPSLEEP, why is MSP430 still used? For waking up, I might use both RTC and a button press so that either event would wake L138 from DEEPSLEEP. Would MSP430 add anything extra here?
Paul
Paul
For 1, if you are talking about entering/exiting Deepsleep mode via RTC Alarm, yes this is what is supported on the LogicPD EVM with the Linux PSP (look for suspend to RAM functionality).
For 2, please see if the following post helps
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/39912/139368.aspx#139368
An external controller is needed to be the "decision maker" on when to toggle the deepsleep pin to come out of deepsleep mode, when DEEPSLEEP pin is used as the mode to enter/exit DEEPSLEEP mode.
Hope this helps
Regards
Mukul
Mukul,
The answer in your linked gives a definitive answer to this question. An external controller would be used or RTC ALARM pin as output would not allow external wake-up inputs. Thanks a lot.
What is the typical time for entering and exiting DEEPSLEEP mode, assuming 300MHz clock ? We have tested ARM and DSP sleep modes which is quite fast, but would DEEPSLEEP be significant slower (referring to Jakez's post "but with 1s resolution on wake up time", but which is probably due to RTC rather than the real waking-up process)?
Paul
Hi Paul
The Linux PSP team is in the process of capturing the suspend/resume wake up latency info for Deep Sleep, I expect this to be available by later half of July. Overall I think this is a system and OS dependent question. 200-300 msec to go into deep sleep and ~300-500 msec to get out of deepsleep withe linux psp , with all peripheral drivers going through suspend/resume , and the context save/restore sounds reasonable. I am sure this number could go down, if the number of peripherals that you need to save and restore context coming in and out of deep sleep is less.
From a hardware perspective, the steps highlighted in the TRM will take about ~ 2msec (including PLL, DEEP Sleep register manipulation etc) but obviously that step guide does not take into consideration the software , peripheral save/restore latency etc.
Regards
Mukul
Mukul,
Great to get the timing figures! We are going to test them on our boards.
Paul
hi mukul,
i am investigating deep sleep performance on omap-L138. One of the parameter is the latency to exit from deep sleep. From the comment above, "The Linux PSP team is in the process of capturing the suspend/resume wake up latency info for Deep Sleep, I expect this to be available by later half of July.". Do you have any latest value on deep sleep latency?
Besides using '"rtcwake" command, can i use "echo mem > /sys/power/state" to put the processor to deep sleep?
Thanks a lot.
lipoh
Lipoh
Details on resume timing etc, are documented as part of the PSP release here
Hope it helps.
Regards
Mukul
Hi Mukul,
i am not able to access the link above. May you help me on this?
Thanks a lot.
Lipoh
hi Mukul,
Really appreciate your reply,
i have take a look on the timing report and found out that some devices take extremely long time to resume. For example:
calling da8xx_lcdc.0+ @ 1298, parent: platform
call da8xx_lcdc.0+ returned 0 after 223391 usecs
does this means that it take 223.391ms to resume? May i know is there any reason it take a long time to resume?
Thanks a lot.
lipoh