OMAP-L138 Power Consumption in DEEPSLEEP

Christina Lam said:

Keep in mind that the power spreadsheet, http://processors.wiki.ti.com/index.php/OMAP-L138_Power_Consumption_Summary, specifies the power for the OMAP-L138 device only. The surrounding hardware on the board (such as memory components, ICs, etc) and power supply efficiency can affect the power footprint of the board, so it is difficult for us to analyze the global power consumption. Is it possible to measure only the core power?

TPS65023 : Should go to low power mode automatically and efficiency should be high
SPI Flash : uA scale when idle
NAND Flash : Below 1mA when idle
DS1307 RTC : Very low power (uA scale)
TLV320AIC3107 : Clock is disabled
64MB DDR2 : Rated at 7mA @ 1.8V in self refresh mode 

Christina Lam said:

The instructions to enter deepsleep, Section 10.10.1.1 in http://www.ti.com/lit/pdf/sprugm7, should get you closest to the lowest deepsleep power footprint. You do not have to PSC disable any other peripherals. The only additional thing that might affect the deepsleep number is the state of the PUPD and DDR_SLEW[CMOSEN] (located in the SYSCFG1 module). Using PUPD_SEL, you'll want to minimize the number of opposing pulls on the pins. Also, when DDR2/mDDR is disabled, set the CMOSEN to LVCMOS receiver mode, which will draw less static power.

Hi,

I tested the DDR_SLEW[CMOSEN] trick but didn't see any improvement.

In the spreadsheet if I configure with the following settings

CVDD : 1.2V
DVDD : 3.3V
DDR2/mDDR : DDR

Press the Static/Deepsleep button I then get : 33.54 mW

If I change to mDDR I get 21.78 mW.

Appart from the CMOSEN bit you told be about is there anything that would limit
the leakage current ? Would I have to change the MSDRAMEN bit in the SDRAM 
controller SDCR register to limit the consumption just before going to sleep and revert
to DDR just before coming out of sleep ?

Best regards,

Christophe

I don't believe there are any additional configurations that would lower the leakage current.  Are you using DDR2/mDDR in your application?  Did you clock gate the DDR before going into deepsleep?

As a point of reference, can you go directly into deepsleep after a power-on reset?  Make sure none of the GEL functions run, so the PLLs are still in bypass mode and none of the peripherals are enabled.  The deepsleep number you get from doing this, should get you closer to the ideal deepsleep number.  If there is a big delta between this deepsleep number and when your application is running, then that means something is not getting turned off in your application.

--Christina

Hi,

I attached a slide from the PRU documentation. (link)

Considering this information, is it possible to be woken up from a PRU event in DEEPSLEEP mode?

In the Power Management chapter of the System Reference Guide, nothing is mentioned about this.

Alper YILDIRIM said:

Considering this information, is it possible to be woken up from a PRU event in DEEPSLEEP mode?

You can only wake up from DEEPSLEEP mode by using the external nDEEPSLEEP or RTC_ALARM pin.  When you enter into DEEPSLEEP mode, the whole chip is clockgated, meaning the DSP, ARM, PRU and all peripherals' state machines are frozen.

In the slide, it is showing that the PRU can utilize the DSP and ARM power down modes.  This will lower the overall usage power.  However, it doesn't lower/affect the deepsleep power. 

--Christina

Christina,

Your post is fantastic! The suggestion of setting DDR_SLEW[CMOSEN] to LVCMOS saved us almost another 20mA of current.

But we still got some questions:

1. We have gone through the TRM SPRUH77 very carefully, in particularly, “10.11.2 DDR2/mDDR Memory Controller Clock Gating and Self-Refresh Mode” and “15.2.16.1 DDR2/mDDR Memory Controller Clock Stop Procedure”. No word has been given there about setting LVCMOS bit. Why the TRM missed it?
2. “11.5.20 DDR Slew Register (DDR_SLEW)” says “The CMOSEN field configures the DDR I/O cells into an LVCMOS buffer (this makes it mDDR compatible).” Is setting this LVCMOS bit safe for retaining data in DDR2, not mDDR? We use self-refresh mode and turned off LPSC_DDR to disable VCLK. After doing this, on the differential DDR2 clock pairs DDR_CLK and DDR_CLKn there is no longer any signal as seen from the oscilloscope. Does this mean that the DDR2 is now totally managed by itself in doing self-refresh for retaining data? If this is indeed the case then We could understand why LVCMOS bit could be set, because DDR2 (NOT mDDR) in self-refresh mode doesn’t rely on external control for operation, so the voltage of DDR I/O pins has no consequence here.
3. We don’t quite understand how can DDR2 in self-refresh mode clock itself. All digital system requires clock, and even in self-refresh mode, which I believe the refresh rate should be much lower than during normal operation, it still need a basic clock reference to control its internal logic, and the clock must also be fast enough to make the refresh rate fast enough to satisfy the physical needs of retaining data (charge). So basically the DDR2 need an internal clock whose speed, albeit being slower than external clock in active mode, be fast and accurate enough for data retaining. Is this correct? And could you provide more insight into this?

Paul

Update:

We have tested self-refresh mode with DDR2. Setting the LVCMOS bit saves an additional 20mA of current. We put both the CPU in DEEPSLEEP mode and DDR2 in self-refresh mode, with LVCMOS set, and wake the CPU up after 1 minute using RTC ALARM, and then take the DDR2 out of self-refresh. All memory contents are perfectly retained.

Paul

Paul

If you are using DDR2 , you will need the CMOSEN bit set to 0 , when actively reading from DDR2 memory. In a standby mode, where you are planning to put DDR2 in "self refresh" and not actively accessing DDR2 memory, it should be ok to set the CMOSEN to 1 (LVCMOS mode) for additional power savings. Just remember as part of wake up from this mode, software should set this bit back to SSTL mode (0), as recommended for DDR2 operations.

Regards

Mukul

Mukul,

This is exactly what we did following Christina's post above. Thanks again for this reconfirmation!

Just very, and very curious why this important information is NOT listed in the TRM SPRUH77 "10.10 Deep Sleep Mode". The power consumption spreadsheet gives a DEEPSLEEP power of 10.93mW, but without setting LVCMOS this ideal state can never be approached!

Paul

Paul/Matt

No good reason, I think the original intent of this section was to provide a chip agnostic overview of some of these modes. There was always a thought process to do a power optimization application note, that would talk about such chip specific details/tips/tricks in more details, unfortunately that remains on the back burner.

It is also assumed that in general users using DDR2 might set this bit to 0 as part of the configuration. For power optimization, this bit can be set to 1 assuming when doing so, there are no accesses to DDR2.

For what it is worth, the delta in power draw you see, is actually modeled in the power estimation spreadsheet, when you select between mDDR vs DDR2 from the drop down menu.  Stop gap, I have also added this assumption in the wiki

http://processors.wiki.ti.com/index.php/OMAP-L138_Power_Consumption_Summary#Example

Regards

Mukul

Mukul,

I do see the updated Wiki text. If this had been added earlier my life in the past few days would be much easier ;)

Thanks and regards,

Paul