DM355 Power Consumption : power down the DSP co-processor

Kapil,

"What I want to know is, is there any way to further reduce the power consumption of DM355 while it is in deep sleep mode? In Deep Sleep mode, is the DSP co-processor core powered down or is it only the ARM that goes to sleep?"

[miguel] The Internal oscillators are power down in deep sleep mode, which in turn turns off the clocks to all the peripherals including the DSP coprocessor.

"Is there any way to power down the DSP core and reduce the power consumption further?"

[miguel] Unfortunately no.

"A related question would be: In out application sometimes we don't use video functionality, but we do need the ARM up and running for say UART communication. In such a mode, is it possible to power down the DSP core and reduce the power consumption? I've already implemented PLL bypass mode and a 48MHz operating mode for DM355 by adjusting the PLLM register(s). So just wondering if there's any additional way to reduce power consumption, perhaps by putting the DSP co-processor to sleep."

[miguel] A higher level power mode is the ARM -wait-for interrupt sleep mode, this enables you to power down the clock the ARM clock until you wake it up using an interrupt, (note: The ARM interrupt controller and the module sourcing the wakeup interrupt (e.g., GIO or WDT) must not be disabled, or the device will never wake up.)

Also, Individual module power down(Including the MJCP)  to conserve power are handled by the PSC controller. 

I hope this helps.

regards,

miguel

Hi Miguel,

Thanks for your answers!

The wait-for-interrupt is what we are using right now to put ARM in deep sleep. An external MSP430 wakes up the DM355 using GIO0.

We are actually working on another operation mode for DM355. In this mode, we want the DM355 ARM core to keep running, but at reduced clock speed. We have programmed it to run at 48MHz. This should save us some power. We use this mode when we are not doing any audio/video processing, but still need to have some operations like UART with GPS and USB with a 3G modem. Our idea is to save some power in this mode by using lower clock rate of ARM (48MHz - already done) and turning off co-processor modules (to be done). I will look into the PSC controller registers for achieving the latter part.

Thanks for the hint!

Best regards,

Kapil

Hi Miguel,

The description of "deepsleep" in the "ARM Subsystem User's Guide" (sprufb3.pdf), table 12-1:

Stop all device clocks and power down internal oscillators to

reduce active power to a minimum. Registers and memory are

preserved.

And section 12.5.1:

· The microcontroller transitions GIO0 from high to low and then continues to hold GIO0 low (for a

minimum of 500 ns) until it desires to exit Deep Sleep mode. The transition of GIO0 from high to low

creates a clock pulse advancing the Deep Sleep state machine. After this transition, all clocks are

stopped and then the internal oscillators are powered down.

· At this point, the DM355 is in Deep Sleep mode; power is reduced to a minimum.

Please correct me if I'm wrong: In deep sleep mode, the ARM and all its internals are really in sleep mode. It can be woken up only by this GIO0 low-->high transition, which basically causes the "deep sleep state machine" to get a clock pulse and advance its state from sleep --> wake up. This means that while it is in deep sleep, it is not polling for any interrupt. In that case, I'd think that deep sleep should consume less power than wait for interrupt. Am I right?

The "Wait for Interrupt" names sounds like the ARM will actually poll for some interrupt. But it's description in the sprufb3.pdf is a bit confusing:

When the wait-for-interrupt mode is

enabled, the clock to the CPU core is shut off and the ARM9 is completely inactive and only resumes

operation after receiving an interrupt.

If the ARM9 is completely inactive, it won't be really polling any interrupt. And thus it should be - well - asleep. Then how is this different from "deepsleep"? I know the go-to0sleep and wake-up procedures are different, but how are the power consumption levels different in these 2 modes?

The description of these to modes doesn't sound quite clear from this document. If the document says that in deepsleep, there is something called "deep sleep state machine" which gets advanced by a transition on GIO0, I'd like to interpret it as NO POLLING, and therefore complete sleep. The document should have stated this clearly. Now I'm really confused. The deepsleep appeals to me because it automatically disabled all internal clocks/oscillators. But then you said it still runs a loop waiting for GIO0. That's wouldn't be great, as it'd mean that ARM9 is not really asleep as in ZZZZZZ.... It's more like a dog sleeping with only one ear awake! :-)

Could you kindly clarify a bit more if possible?

Thanks a ton!

Kapil

Ah! I just re-read my last message and realized a subtle difference in the description of deepsleep and wait-for-interrupt in that sprufb3.pdf.

Deepsleep: "power is reduced to a minimum"

Wait-for-interrupt: "the ARM9 is completely inactive"

Power reduced to minimum should mean "active power" *reduced* to minimum. Not zero. On the other hand, "completely inactive" sounds like "active power" consumption would be really zero.

If this is it, I'd really like this to be stated very clearly in the sprufb3.pdf. Right now it is a bit confusing.

Now, if what I've said above is correct, can we use GIO0 to come out of "wait-for-interrupt"? I ask this because on our hardware, a line form MSP430 is tied up with GIO0 of the DM355. That's what we currently use to come out of "deepsleep". It'd be really great if I could just change my code get "wait-for-interrupt" to work on the same hardware. If we work on the same hardware - if GIO0 cannot be used for wait-for-interrupt (perhaps reserved for some other special purpose, e.g. only for deepsleep?) then we might have to make some hardware change.

Best regards,

Kapil

Can you give me some codes about DM365 with DEEPSLEEP.

My email is samozhishui@163.com.

thanks

Kapil,

I'll look into this futher next week, as I am very tied up at the moment.  But in the meanwhile I am going to attach a sample code that I used for dm355 deep sleep and one for wait4int this might clarify better.

Others,

This dm355 can be used as a reference only to generate a similar testcase for DM365, of course there are many differences between the 2 devices so this is only a sample for reference only.

regards,

miguel

adding a wait4int sample code.

regards,

miguel

Thank you Migual!!

can this codes run in dm365?

 can you tell me the frequence which is best for DM365 to work in deepsleep mode?

and in deepsleep mode :tell me the order to power down the module!

thanks !

In deep sleep mode ARM is sleeping. It is not running. If you want to run DM355/DM365 in low speed mode, you might want to consider PLL bypass mode. But some devices do not work in this mode, such as USB. I faced this problem with USB modem connected to the DM355. In PLL bypass mode, it doesn't work because there is some limitation that  the USB subsystem source clock has to be above a certain threshold.

OS linux support lower power management. why don't you use the linux system to reduce power?

I'm not sure what you are referring to. We already use the Linux Power Mgmt... look at files in "arch/arm/mach-davinci/" and in "kernel/power", that is where the deepsleep and pll bypass is implemented. You invoke the power state changes by using the Linux Power Mgmt interface at /sys/power/state.

Hi Kapil,

Just to confirm, are you using LSP 2.00.xx or LSP 3.xx.xx for DM355 to use power management? We also plan to use it in our system, so wanted to confirm before starting on it.

Regards,

Anshuman

OK, but I can not find the file /sys/power/state.

And which way I can achieve deepsleep?

 Can you give me concrete method to come ture the deepsleep!!

thank you!

can you give me your linux kernel.  I think my linux does not support you said!

thak

can you give me your linux kernel.  I think my linux does not support you said!

thank

can you give me your linux kernel.  I think my linux does not support you said!

thank you

can you give me your linux kernel.  I think my linux does not support you said!

thank you !!

The DM355 Code will not(and should not) run on DM365 because they are different devices, and their system registers are different etc...

I stated on my earlier post that dm355 code can only be used as reference for dm365, (code structure, flow etc..) the register settings will be vey different between the two devices.

regards,

miguel

Anshuman,

I am using LSP 1.20 :-) I know it's way too old, but lot of our code was based on that and seemed to get broken when we tried to upgrade. Hence, I have just back ported the deepsleep code (or applied patches available somewhere here) - can't remember right now.

Regards,

Kapil

Hello Miguel, this is Magda from Spain.

Is this the last version for implementing deep sleep mode on dm355?

if so, I have few questions about the code, do you have any wiki or documentation?

Thanks a million!

Magda,

the sample dm355 sleep code I provided is there as reference only, it is by no means production code, it is there to help customers/users how to be able to put the dm355 in deepsleep mode :) , please send in your questions and I'll try to answer them, I'm not actively supporting this device for a while now as I have moved to other device support, but I will try to answer your questions in a timely matter.

regards,

miguel

Muchas gracias Miguel!

Your code is a very good guide for implemeting deep sleep mode on dm355, thanks for making it available!

Between your code (DM355_DEEPSLEEP_FINAL.zip) and the sprufb3a.pdf document I am trying to make production code.

Here are few general questions, I hope you can help me:

Have you used the GEL file provided (DM35x_POWERTEST.GEL) for doing your other report spraaz5a.pdf about measuring power consumption?

Iis the code included into the GEL file equal to the one included into main_deepsleep_final.c? What is the difference?

and lastly, when and how is the deepsleep.out application called? is it a process running on the background an waiting for a change on GIO0?

Some support would be greatly appreciate it!

Thanks a million!

Magda