Hello,
Have you succeeded in taking the DM355 to sleep and back to wakeup?
Well I have tried the patch and I'm not sure if the processor has really
waken up, for I'm not able to see the login prompt.
However, I'm able to see a current consumption difference of 75mA after
waking up though the Linux prompt is not observable.
The system hangs after the wakeup procedure and I could not do anything
except a reset.
To take the processor to the power down mode, I am taking the PIN1.3 of
the MSP430 through an IAR JTAG emulator. This is connected to GIO000 of
the DM355. the wakeup is also controlled by writing a 1 directly to the
PIN1.3.
Could someone please help me find out what I'm missing?
One more thing - The ARM subsystem guide does not mention whether
asserting the GIO000 high take the processor just to the last
instruction before freezing or will it branch to an interrupt(GIO000
interrupt). I understand that the entry point is the instruction just
after the sleep point. Or should I have to write an ISR for this?
Thank you!
Here is the patch code(previously sent by Jeff)
Cheers,
Deepak
////////////////////////////////////////////////////////////////////////
/////
////////////////////////////////////////////////////////////////////////
/////
enter_ddr_self_refresh:
ldr r0, SDRCR_ADDR
ldr r2, [r0]
ldr r1, SDRCR_SR_PD_MASK
bic r2, r2, r1
ldr r1, SDRCR_LPMODEN_MASK
orr r2, r2, r1
str r2, [r0]
////////////////////////////////////////////////////////////////////////
/////
////////////////////////////////////////////////////////////////////////
/////
/* ToDo: Wait T_CKE+1 cycles */
mov r2, #0x1000
loop1:
subs r2, r2, #0x1
bne loop1
////////////////////////////////////////////////////////////////////////
/////
////////////////////////////////////////////////////////////////////////
/////
/* Make GPIO 6 line HIGH just before entering into sleep
mode. */
ldr r3, GPIO_OUT_01_ADDR
ldr r5, [r3]
ldr r4, GPIO_006_HIGH
orr r5, r5, r4
str r5, [r3]
ldr r0, deepsleep_reg
/* Reset SLEEP COMPLETE bit before enabling Deep Sleep */
ldr r2, [r0]
ldr r1, deepsleep_cmplt
bic r2, r2, r1
str r2, [r0]
ldr r2, [r0]
ldr r1, deepsleep_enbl
orr r2,r2,r1
str r2, [r0]
// Poll SLEEP COMPLETE bit till wakeup is completed.
ldr r1, deepsleep_cmplt
sleep_complete:
/* Wait for SLEEP_COMPLETE bit */
ldr r2, [r0]
ands r2, r2, r1
beq sleep_complete
/* Make GPIO 6 line low immediately after wake up from Deep
Sleep mode. */
ldr r3, GPIO_OUT_01_ADDR
ldr r5, [r3]
ldr r4, GPIO_006_HIGH
bic r5, r5, r4
str r5, [r3]
ldr r2, [r0]
ldr r1, deepsleep_enbl
bic r2, r2, r1
str r2, [r0]
////////////////////////////////////////////////////////////////////////
/////
////////////////////////////////////////////////////////////////////////
/////
exit_ddr_self_refresh:
ldr r0, SDRCR_ADDR
ldr r2, [r0]
ldr r1, SDRCR_SR_PD_MASK
orr r2, r2, r1
ldr r1, SDRCR_LPMODEN_MASK
bic r2, r2, r1
str r2, [r0]
////////////////////////////////////////////////////////////////////////
/////
////////////////////////////////////////////////////////////////////////
/////
/* ToDo: Wait T_SXNR+1 and/or T_SCRD+1 cylces */
mov r0, #0x1000
loop2:
subs r0, r0, #0x1
bne loop2
/* Make GPIO 6 line HIGH just before return. */
ldr r3, GPIO_OUT_01_ADDR
ldr r5, [r3]
ldr r4, GPIO_006_HIGH
orr r5, r5, r4
str r5, [r3]
/* Resume*/
ldmfd sp!, {r0 - r12, pc} @ restore regs and
return
////////////////////////////////////////////////////////////////////////
/////
////////////////////////////////////////////////////////////////////////
/////
ddr2_ctrl_base:
.word DDR2_CTRL_VIRT
self_refresh:
.word 0x80000000
deepsleep_reg:
.word 0xE1040048
deepsleep_enbl:
.word 0x80000000
deepsleep_cmplt:
.word 0x40000000
GPIO_BASE:
.word 0xE1067000
GPIO_DIR_01_ADDR:
.word 0xE1067010
GPIO_OUT_01_ADDR:
.word 0xE1067014
GPIO_SET_01_ADDR:
.word 0xE1067018
GPIO_CLEAR_01_ADDR:
.word 0xE106701C
GPIO_006_HIGH:
.word 0x00000040
GPIO_006_LOW:
.word 0x00000000
GPIO_007_HIGH:
.word 0x00000080
SDRCR_ADDR:
.word 0xFEB0000C
SDRCR_LPMODEN_MASK:
.word 0x80000000
SDRCR_MCLKSTOPEN_MASK:
.word 0x40000000
SDRCR_SR_PD_MASK:
.word 0x00800000
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Griffis, Brad
Sent: Friday, September 26, 2008 7:00 AM
To: Jeff Cooper; Sun, ChengHao
Cc: [email protected]
Subject: RE: Deep sleep on the DM355
Jeff,
That's correct that the refresh rate refers to the rate that the DDR
controller will refresh the DDR. In self-refresh mode the DDR is
refreshing itself.
Brad
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Jeff Cooper
> Sent: Wednesday, September 24, 2008 9:08 AM
> To: Sun, ChengHao
> Cc: [email protected]
> Subject: Re: Deep sleep on the DM355
>
> Sun,
>
> I actually didn't look at the patch that closely. Since I was going
> to use it on a DM355 and not on a DM644x that it was originally
> written for, I just replaced the self-refresh code with what is
> correct for the DM355.
>
> After reviewing it, I'd agree with you that there seems to be a bug, I
> don't think this will enter self refresh mode. The SDRCR register is
> at 0x2000 000c on both the DM644x and the DM355. So I don't see how
> this code ever worked. The code I'm using to enter self-refresh on
> the
> DM355 looks like:
>
> /**
> * Switch DDR to self-refresh mode.
> */
> enter_ddr_self_refresh:
> ldr r0, SDRCR_ADDR
> ldr r2, [r0]
>
> ldr r1, SDRCR_SR_PD_MASK
> bic r2, r2, r1 @ Clear the SR_PD
bit
>
> ldr r1, SDRCR_LPMODEN_MASK
> orr r2, r2, r1 @ Set the LPMODEN
bit
>
> str r2, [r0]
>
> bx lr @ return
>
> SDRCR_ADDR: .word DDR2_CTRL_VIRT + 0x0c
> SDRCR_LPMODEN_MASK: .word 0x80000000
> SDRCR_MCLKSTOPEN_MASK: .word 0x40000000
> SDRCR_SR_PD_MASK: .word 0x00800000
>
> I don't believe that the Refresh Rate is used in self-refresh mode. I
> think that the DDR chip itself is handling the rate in that case.
> Someone please correct me if I'm wrong.
>
> thanks,
> Jeff
>
> Sun, ChengHao wrote:
> > Hi Jeff,
> > I reviewed the code and some confused about some operation, In
> > patches:
> >
> > + /* Switch SDRAM to selfrefresh */
> > + ldr r0, ddr2_ctrl_base
> > + ldr r1, self_refresh
> > + ldr r2, [r0]
> > + orr r2, r2, r1
> > + str r2, [r0]
> > ...
> >
> > +ddr2_ctrl_base:
> > + .word DDR2_CTRL_VIRT
> > +self_refresh:
> > + .word 0x80000000
> > ...
> > +#define DDR2_CTRL_PHYS DAVINCI_DDR2_CTRL_BASE /* 0x20000000 */
> > +#define DDR2_CTRL_VIRT 0xfeb00000 #define DDR2_CTRL_SIZE SZ_1M
> > ...
> > + {
> > + .virtual = DDR2_CTRL_VIRT,
> > + .pfn = __phys_to_pfn(DDR2_CTRL_PHYS),
> > + .length = DDR2_CTRL_SIZE,
> > + .type = MT_DEVICE
> > + },
> > ...
> >
> >
> > Can I say, the code try to write 0x80000000 into 0x20000000 to make
> > DDR into self refresh mode?
> > But refer the tms320dm6446.pdf Table 6-36. DDR2 Memory Controller
> > Registers in http://focus.ti.com/lit/ds/symlink/tms320dm6446.pdf and
> > the Table 23.
> > SDRAM Refresh Control Register (SDRCR) Field Descriptions in
> > TMS320DM644x DMSoC DDR2 Memory Controller User's Guide in
> > http://focus.ti.com.cn/cn/lit/ug/sprue22c/sprue22c.pdf,
> >
> > We should write control word to 0x2000 000C,
> >
> > And one more issue I am not sure: the control word need also include
> > Refresh rate for self refresh mode or not? Means should write
> > 0x8000xxxx to 0x2000000C to make it refresh, right?
> >
> > Best Regards
> > Sun
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Jeff Cooper
> > Sent: Friday, September 12, 2008 1:27 AM
> > To: Deepak Shankar-TLS,Chennai.
> > Cc: [email protected]
> > Subject: Re: Deep sleep on the DM355
> >
> > Deepak,
> >
> > I've modified the LSP 1.20 source tree to add in this patch:
> >
> >
> > http://www.mail-archive.com/[EMAIL PROTECTED]
> > sp.c
> > om/msg04407.html
> >
> > Since it's for the git tree, it didn't apply, but it gave me enough
> > info
> >
> > to get similar support on the 1.20 source tree.
> >
> > Part of being about to go into deep sleep is to put your DDR into
> > self-refresh mode. The only place you can do that is while you're
> > running out of TCM. Part of the patch creates sleep.S which are
> > some ASM routines that get copied into TCM. When you want to
> > suspend, you jump to the routine in TCM and then it's safe to shut
down the DDR.
> >
> > After I've shut down the DDR, then I send a I2C command to an
> > external processor (an MSP430) in my case to tell it I'm ready to
> > sleep and to drop the GIO0 line. My ASM code looks like:
> >
> > /* Inform the MSP that we're going into deep sleep */
> > ldr r0, MSP_I2C_ADDRESS
> > adr r1, MSP_CMD_SLEEP @ load r1 with the address
of
> > MSP_CMD_SLEEP
> > ldr r2, MSP_CMD_SLEEP_BYTES
> > bl i2c_send_data
> >
> > /* Enter deep sleep */
> > ldr r0, SYS_DEEPSLEEP_ADDR
> > ldr r2, [r0] @ load the contents
of
> > the deepsleep reg
> >
> > ldr r1, SYS_DEEPSLEEP_ENABLE_MASK
> > orr r2, r2, r1 @ set the enable bit
> > str r2, [r0]
> >
> > ldr r1, SYS_DEEPSLEEP_COMPLETE_MASK
> > sleep_complete:
> > ldr r2, [r0] @ load the deep
sleep
> > reg
> > ands r2, r2, r1 @ test if the
complete
> > bit is set
> > beq sleep_complete @ if it's not 1,
keep
> > waiting
> >
> > ldr r1, SYS_DEEPSLEEP_ENABLE_MASK
> > bic r2, r2, r1 @ clear the enable
bit
> > str r2, [r0]
> >
> > What do you mean by 'cutdown the core-clock'? I'm not changing my
> > clock
> >
> > rate at all. My understanding is that deep sleep mode shuts down
> > all clocks and that that wouldn't have any effect.
> >
> > What section of SPRUFB3 (I assume that's the one you mean, I can't
> > find SPRUB3), are you quoting from?
> >
> > thanks,
> > Jeff
> >
> > Deepak Shankar-TLS,Chennai. wrote:
> >
> >> I'm also working on this but have not succeeded to take the system
> >> to sleep yet.
> >> Could you please tell me if you just set the GIO000 to low to take
> >> it
> >>
> > to
> >
> >> sleep?
> >>
> >> However regarding the other peripherals it looks like we have to
> >>
> > disable
> >
> >> the outputs of PSC entirely.
> >> Have you also cutdown the core-clock?
> >>
> >> The SPRUB3 mentions
> >> "To reduce the chip stand by power, it is advised to power down all
> >>
> > the
> >
> >> analog blocks (PLL cores, DDR
> >> PHY DLL, DDR PHY, USB PHY, Video DAC, and CCP PHY). "
> >>
> >>
> >> -----Original Message-----
> >> From:
> >> [EMAIL PROTECTED]
> >> davinci-linux-open-source-bounces+om
> >>
> >>
> > [mailto:[EMAIL PROTECTED]
> > cids
> >
> >> p.com] On Behalf Of Jeff Cooper
> >> Sent: Thursday, September 11, 2008 8:39 PM
> >> To: [email protected]
> >> Subject: Deep sleep on the DM355
> >>
> >> I'm trying to enable deep sleep on a DM355 and I'd like to know if
> >> anyone else has done that?
> >>
> >> I think that I've been able to enter and exit deep sleep mode
> >> successfully as I see the power draw on my system drop from 650 mW
> >>
> > down
> >
> >> to 190 mW when I'm in deep sleep.
> >>
> >> There's very little hard information on how much power the DM355
> >>
> > should
> >
> >> draw in deep sleep mode. I've found a Power Point presentation on
> >> the net at:
> >>
> >>
> >>
> > http://www.arrownac.com/manufacturers/texas-instruments/npi/products
> > /dm3
> >
> >> 55/davinci-dm355.ppt
> >>
> >>
> >> that states that the power consumption should be less that 5 mW
> >> while it's in deep sleep.
> >>
> >> I've also found a FAQ from TI that states that it should be approx
> >> 1
> >>
> > mW:
> >
> >> http://focus.ti.com.cn/cn/lit/ml/sprv063a/sprv063a.pdf
> >>
> >> Assuming that the DM355 is in deep sleep mode and is really drawing
> >> around 5 mW, when I add in the maximum power draw from the other
> >> major components on my system, I'm still pretty far away from from
> >> what I'd expect the system to be drawing.
> >>
> >> The documentation in the Arm Subsystems User Guide (SPRUFB3)
> >> section
> >> 12.5.1 states:
> >>
> >> 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.
> >>
> >> I may be misunderstanding that statement, but I took it to mean
> >> that
> >>
> > the
> >
> >> system is in it's lowest power state at that point. I suspect that
> >>
> > that
> >
> >> may not be entirely true. I found that the VPSS oscillator, OTG
> >>
> > analog
> >
> >> block and USB PHY are still powered on. Turning those off saves
> >> about
> >> 12 mW.
> >>
> >> I suspect that other areas of the DM355 are still drawing power.
> >> Does anyone know of other areas of the chip that should be powered
> >> off separately prior to entering deep sleep?
> >>
> >> I've tried turning off the VPSS_Master and VPSS_Slave using the PSC
> >> controller, but that didn't have any noticeable effect.
> >>
> >> Does the PSC have any effect on power consumption when the system
> >> is
> >>
> > in
> >
> >> deep sleep mode?
> >>
> >> Does anyone know if the DSP side goes to sleep when you enter deep
> >> sleep?
> >>
> >> I've also noticed that the amount of power that the system consumes
> >>
> > can
> >
> >> very quite a bit between various deep sleeps. Using a software
> >> load that boots the kernel and puts the system to sleep, I've seen
> >> as much
> >>
> > as
> >
> >> 31 mW variance between boots once the system has entered deep
sleep.
> >> I've yet to figure that one out.
> >>
> >> Any ideas on things to try or look into would be appreciated.
> >>
> >> thanks,
> >> Jeff
> >>
> >> --
> >> Jeff Cooper // senior embedded software engineer
> >>
> >> LOGIC // engineering design services
> >> 411 Washington Ave. N. Suite 400
> >> Minneapolis, MN 55401
> >> T // 612.436.5176
> >> F // 612.672.9489
> >>
> >> [EMAIL PROTECTED]
> >> www.logicpd.com
> >>
> >> / / / / / / / / / / / / / / / / / / / / / / / / / / / /
> >>
> >> This message (including any attachments) contains confidential
> >> information intended for a specific individual and purpose, and is
> >> protected by law. If you are not the intended recipient, you
> >> should delete this message and are hereby notified that any
> >> disclosure, copying, distribution, or other use of this message,
> >> or the taking of any action based on it, is strictly prohibited.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Davinci-linux-open-source mailing list
> >> [email protected]
> >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-sou
> >> rce
> >>
> >> DISCLAIMER:
> >>
> >>
> > --------------------------------------------------------------------
> > ----
> > -----------------------------------------------
> >
> >> The contents of this e-mail and any attachment(s) are confidential
> >> and
> >>
> > intended for the named recipient(s) only.
> >
> >> It shall not attach any liability on the originator or HCL or its
> >>
> > affiliates. Any views or opinions presented in
> >
> >> this email are solely those of the author and may not necessarily
> >>
> > reflect the opinions of HCL or its affiliates.
> >
> >> Any form of reproduction, dissemination, copying, disclosure,
> >>
> > modification, distribution and / or publication of
> >
> >> this message without the prior written consent of the author of
> >> this
> >>
> > e-mail is strictly prohibited. If you have
> >
> >> received this email in error please delete it and notify the sender
> >>
> > immediately. Before opening any mail and
> >
> >> attachments please check them for viruses and defect.
> >>
> >>
> >>
> > --------------------------------------------------------------------
> > ----
> > -----------------------------------------------
> >
> >>
> >>
> >
> >
> >
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> [email protected]
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
