Questions about OMAP-L138 DEEPSLEEP sequence

john filo

Other Parts Discussed in Thread: OMAP-L138

We're building an OMAP-L138 board that we'd like to be able to programatically put into DEEPSLEEP and wake with an external signal. SPRUH77A (OMAP-L128 Ref Manual), page 218 describes the procedure for entering deep sleep as follows:

   7. Configure the DEEPSLEEP pin as input-only pin..
   8. The external controller should drive the DEEPSLEEP pin high.
   9. Configure the desired delay in the SLEEPCOUNT bit field...
   10. Set the SLEEPENABLE bit in DEEPSLEEP to 1
   11. Begin polling the SLEEPCOMPLETE bit...
   12. The external controller drives DEEPSLEEP log to initiate Deep Sleep mode.

My questions are:

1) Is it okay to use GPIO lines to trigger DEEPSLEEP after step 10?

2) If the answer to 1 is no, then does the OMAP require a transition from high to low on the DEEPSLEEP after SLEEPENABLE is set to 1, or does it just look for a low? If the former, then it seems like step 8 is required to occur before step 10 and step 12 is required to happen after. But if the latter is adequate it seems like step 8 could be omitted and step 12 could happen anytime before 11, which could simplify the circuitry necessary to drive the DEEPSLEEP pin.

Thanks,

John Filo

over 11 years ago

0 Titusrathinaraj Stalin over 11 years ago

TI__Guru** 116100 points

Hi John,

1) Is it okay to use GPIO lines to trigger DEEPSLEEP after step 10?

As per my understanding,

Yes, It is possible to put the processor in DS mode through GPIO, but It is not recommended as the wakeup should be happening through external controller to drive it high for DEEPSLEEP pin (all the module clocks were gated).

Earlier, I have done this DS mode in some old processors like DM355,
I have configured and enable the deepsleep mode for DEEPSLEEP pin through GPIO.

Note:

I have not tried to wakeup the processor from DS mode because, external controller is not available on my board to drive high for wakeup.

As per the TRM,

Due to pin multiplexing, the DEEPSLEEP pin can only be driven by an external controller or its internal real-time clock (RTC). The DEEPSLEEP pin cannot be driven by both an external controller and its internal real-time clock at the same time.

I have to try this through experiments and let me update and also update us If you found,

2) If the answer to 1 is no, then does the OMAP require a transition from high to low on the DEEPSLEEP after SLEEPENABLE is set to 1, or does it just look for a low?

Please refer the TRM chapter 10.10.3 & clocking diagram

Step 8 ensures that the processor is not already been in DS mode,

Processor requires the "High to Low" transition on DEEPSLEEP pin to put the processor in DS mode.

For wakeup, The Processor requires the "High" until SLEEPCOMPLETE is set (need to disable you disable SLEEPENABLE) on DEEPSLEEP pin,

Please refer the following DS reference threads which you may find interesting.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/103695.aspx
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/290483.aspx
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/245777/861758.aspx#861758

0 john filo over 11 years ago in reply to Titusrathinaraj Stalin

Intellectual 260 points

Thanks for the quick reply.

Titusrathinaraj Stalin said:

1) Is it okay to use GPIO lines to trigger DEEPSLEEP after step 10?

Yes, It is possible to put the processor in DS mode through GPIO, but It is not recommended as the wakeup should be happening through external controller to drive it high for DEEPSLEEP pin (all the module clocks were gated).

[/quote]

I wasn't very clear in my original question. The specific part I was uncertain about was whether or not I could use the GPIO lines at all after step 10. I was concerned that step 6, powering down the PLLs, would prohibit use of the GPIO lines (I'm not sure why; I'm a little hazy on what the PLLs do; I thought they provided various module clocks and so powering them down would effectively disable those modules). We won't be driving DEEPSLEEP directly from the GPIO line but rather using a GPIO to trigger some external circuitry to drive DEEPSLEEP. My thinking was that if powering down the PLLs prohibited use of the GPIO lines then I wouldn't be able to trigger DEEPSLEEP after step 10 (setting SLEEPENABLE to 1) but rather I'd have to do it before step 6. If that were true, then I was hoping a simple level check was being done when SLEEPENABLE was set to 1 so the external circuit could simply drive DEEPSLEEP low prior to powering down the PLL. If a transition is required, and GPIOs could only be used prior to powering down the PLLs, then we'll have to have a more complicated external circuit because the GPIO would have to trigger a delayed high to low transition on the DEEPSLEEP line. I don't know if that makes sense, but the bottom line is that if it's okay to use the GPIO module after powering down the PLLs then I think our design will work.

I assume there are some limits to what can be done between step 6 and 10 (i.e. between powering down the PLLs and setting SLEEPENABLE).

Due to pin multiplexing, the DEEPSLEEP pin can only be driven by an external controller or its internal real-time clock (RTC).

The DEEPSLEEP pin cannot be driven by both an external controller and its internal real-time clock at the same time.

We want to use both an RTC and an external signal to control wakeup, so we'll be adding an external RTC for this purpose.

Thanks for the info.

John Filo

0 Titusrathinaraj Stalin over 11 years ago in reply to john filo

TI__Guru** 116100 points

Hi,

I was concerned that step 6, powering down the PLLs, would prohibit use of the GPIO lines (I'm not sure why; I'm a little hazy on what the PLLs do; I thought they provided various module clocks and so powering them down would effectively disable those modules). We won't be driving DEEPSLEEP directly from the GPIO line but rather using a GPIO to trigger some external circuitry to drive DEEPSLEEP.

You are able to modify the GPIO values even though PLL is in self refresh mode or power down mode because it is in still active with bypass clock (Ref : 24MHz) and It is complete in-active when DS enabled.

I am able to run the linux OS when the processor is in PLL bypass mode and PLL powerdown mode,

but it is too slow,

This is just experiment which i have tried earlier,

We wont recommend GPIO for DS mode for wakeup as well initiate DS,

The below example code that I used earlier for PLL power down mode in DM355,

Surely I will try this experiments and will update,

Ex :

MODULE_LICENSE("GPL");

/* Init Module */
static int pllpowerdown_init(void)
   {
   printk(KERN_ERR "pll powerdown module init\n");
   unsigned int ret;
   unsigned int *PLLCTL = PLLCTL = ioremap(0x01c40900,4);//PLL control register to power down the PLL clock
   ret = *PLLCTL;
   printk(KERN_ERR "plltl old value = %p\n",*PLLCTL);
   ret &= 0xfffffff0;
   ret |= 0x00000000;//PLLEN=0(bypass mode)
   *PLLCTL = ret;
   printk(KERN_ERR "pllctl new value = %p\n",*PLLCTL);
   msleep(1000);//wait atleast 4 reference clock mux to change
   ret &= 0xfffffff0;
   ret |= 0x00000002;//PLLPWRDN=1(power down the PLL)
   *PLLCTL = ret;
   printk(KERN_ERR "pllctl new value after pll powerdown = %p\n",*PLLCTL);
   return 0;
   }

/* Exit Module */
static void pllpowerdown_exit(void)
   {
   unsigned int *PLLCTL = PLLCTL = ioremap(0x01c40900,4);//PLL control register to power down the PLL clock
   printk(KERN_ERR "pllctl value before exit is = %p\n",*PLLCTL);
   *PLLCTL = 0x00000041; //Resetting old values {PLL Powering up}
   printk(KERN_ERR "pllctl value after exit is = %p\n",*PLLCTL);
   printk(KERN_ERR "pll powerdown module exit\n");
   }

/* Register driver to the kernel */
module_init(pllpowerdown_init);
module_exit(pllpowerdown_exit);

0 john filo over 11 years ago in reply to Titusrathinaraj Stalin

Intellectual 260 points

We wont recommend GPIO for DS mode for wakeup as well initiate DS,

Your answer about GPIO while PLL is powered down answers my question. Thanks. But I'm curious; if you don't recommend GPIO initiated DEEPSLEEP how would you recommend we implement software initialted DEEPSLEEP wiith an external wake signal? Once again, we're not driving DEEPSLEEP directly from a GPIO line; the GPIO is going to be used to trigger an external circuit that will control the DEEPSLEEP line.

0 Titusrathinaraj Stalin over 11 years ago in reply to john filo

TI__Guru** 116100 points

Hi,

If you are controlling DS pin through external device for sleep/wake then surely it will work,

Processors

Processors forum

Questions about OMAP-L138 DEEPSLEEP sequence