PPC405 sleep?

I am trying to put the PPC405 asleep on a VirtexIIPro ML310 Xilinx 
development board and not have a lot of luck. I'm running VxWorks and have 
written a little application that toggles an LED so that I know the task is 
running. I've tried two methods--with drastically different results-- but 
neither of which do everything I need.

First try:

 I loaded my app that toggles LEDs via a Tornado shell.

Spawn the LED toggler.

Note that via Tornado shell, I see LED toggler in the task list at an "i" 
command. Note that via the serial shell, I cannot see LED toggler in the 
task list at an "i" command.

Disable PIT, so only a UART or network source interrupt will awaken me (ie 
no sysClk/timer interrupts)

Put to sleep via  MSR[WE].  Observed LED quits toggle-- as expected.

Then, via a SERIAL shell, I type "i", and vxWorks awoke and printed the 
tasks data as expected-but the LED toggler did not resume execution.

Second try:

I moved all this code into UsrAppInit and then programmatically, spawned the 
LED toggler. Wait a few secs (so I can observe LED on scope). Then Disable 
PIT and put to sleep.

Now, I try to awaken the PPC405 via the serial connection. I cannot seem to 
waken the PPC at all. If/when it wakens, the next line of code in usrAppInit 
would have printed out an "Awoken" message--but I never see this happen.

Note that the Msr register is set to 0x00069200 to initiate the sleep-which 
should set the sleep bits, and enable critical and external interrupts 
(though the PIT as a possible feeder to External Interrupt has been disabled 
via a write to TCR of 0x00040000...)

Someone else had mentioned to me the need for possible sync and orderly 
execution before putting the PPC to sleep, so I added "sync, isync, and 
eieio" code immediately prior to the set MSR[WE] bit, but this made no 
difference. Any ideas?

Thanks

Paul

Bo said the following:
> I am trying to put the PPC405 asleep on a VirtexIIPro ML310 Xilinx 
> development board and not have a lot of luck. I'm running VxWorks and have 
> written a little application that toggles an LED so that I know the task is 
> running. I've tried two methods--with drastically different results-- but 
> neither of which do everything I need.
> 
> First try:
> 
>  I loaded my app that toggles LEDs via a Tornado shell.
> 
> Spawn the LED toggler.
> 
> Note that via Tornado shell, I see LED toggler in the task list at an "i" 
> command. Note that via the serial shell, I cannot see LED toggler in the 
> task list at an "i" command.
Well, I'd expect you see it, but not with the expected symbolic name. As
you loaded the code via host shell, you'd need to include host sym table
sync to your target's image.

> 
> Disable PIT, so only a UART or network source interrupt will awaken me (ie 
> no sysClk/timer interrupts)
> 
> Put to sleep via  MSR[WE].  Observed LED quits toggle-- as expected.
> 
> Then, via a SERIAL shell, I type "i", and vxWorks awoke and printed the 
> tasks data as expected-but the LED toggler did not resume execution.
> 
How should it?
You disabled timer interrupt!

> Second try:
> 
> I moved all this code into UsrAppInit and then programmatically, spawned the 
> LED toggler. Wait a few secs (so I can observe LED on scope). Then Disable 
> PIT and put to sleep.
> 
> Now, I try to awaken the PPC405 via the serial connection. I cannot seem to 
> waken the PPC at all. If/when it wakens, the next line of code in usrAppInit 
> would have printed out an "Awoken" message--but I never see this happen.
> 
> Note that the Msr register is set to 0x00069200 to initiate the sleep-which 
> should set the sleep bits, and enable critical and external interrupts 
> (though the PIT as a possible feeder to External Interrupt has been disabled 
> via a write to TCR of 0x00040000...)
> 
> Someone else had mentioned to me the need for possible sync and orderly 
> execution before putting the PPC to sleep, so I added "sync, isync, and 
> eieio" code immediately prior to the set MSR[WE] bit, but this made no 
> difference. Any ideas?
> 
First action in your UART's ISR should be to re-enable timer interrupt.
This is a major device, VxWorks can't run without it properly.

HTH

-- 
Regards,
Mit freundlichen Gr��en,
Michael Lawnick

HTML-Mail is the first choice to distribute EMail-worms and -virii.
Back to the roots!

Michael,

Thanks for taking a look. I changed the ext int ISR in vxWorks to always set 
the PIT enable and PIT auto-reload bits (in case the execution of ISR was 
the first execution after being put to sleep) and got the exact same 
results. Any ideas?

You were right that the LED toggler did show up in the "i" command 
response--under a different name-and as 'READY'--however it was not 
executing. (???)

Thanks again...

Paul


"Michael Lawnick" <m.lawnick@kontron-applications.de> wrote in message 
news:4214442d_2@news.arcor-ip.de...
> Bo said the following:
>> I am trying to put the PPC405 asleep on a VirtexIIPro ML310 Xilinx
>> development board and not have a lot of luck. I'm running VxWorks and 
>> have
>> written a little application that toggles an LED so that I know the task 
>> is
>> running. I've tried two methods--with drastically different results-- but
>> neither of which do everything I need.
>>
>> First try:
>>
>>  I loaded my app that toggles LEDs via a Tornado shell.
>>
>> Spawn the LED toggler.
>>
>> Note that via Tornado shell, I see LED toggler in the task list at an "i"
>> command. Note that via the serial shell, I cannot see LED toggler in the
>> task list at an "i" command.
> Well, I'd expect you see it, but not with the expected symbolic name. As
> you loaded the code via host shell, you'd need to include host sym table
> sync to your target's image.
>
>>
>> Disable PIT, so only a UART or network source interrupt will awaken me 
>> (ie
>> no sysClk/timer interrupts)
>>
>> Put to sleep via  MSR[WE].  Observed LED quits toggle-- as expected.
>>
>> Then, via a SERIAL shell, I type "i", and vxWorks awoke and printed the
>> tasks data as expected-but the LED toggler did not resume execution.
>>
> How should it?
> You disabled timer interrupt!
>
>> Second try:
>>
>> I moved all this code into UsrAppInit and then programmatically, spawned 
>> the
>> LED toggler. Wait a few secs (so I can observe LED on scope). Then 
>> Disable
>> PIT and put to sleep.
>>
>> Now, I try to awaken the PPC405 via the serial connection. I cannot seem 
>> to
>> waken the PPC at all. If/when it wakens, the next line of code in 
>> usrAppInit
>> would have printed out an "Awoken" message--but I never see this happen.
>>
>> Note that the Msr register is set to 0x00069200 to initiate the 
>> sleep-which
>> should set the sleep bits, and enable critical and external interrupts
>> (though the PIT as a possible feeder to External Interrupt has been 
>> disabled
>> via a write to TCR of 0x00040000...)
>>
>> Someone else had mentioned to me the need for possible sync and orderly
>> execution before putting the PPC to sleep, so I added "sync, isync, and
>> eieio" code immediately prior to the set MSR[WE] bit, but this made no
>> difference. Any ideas?
>>
> First action in your UART's ISR should be to re-enable timer interrupt.
> This is a major device, VxWorks can't run without it properly.
>
> HTH
>
> -- 
> Regards,
> Mit freundlichen Gr&#4294967295;&#4294967295;en,
> Michael Lawnick
>
> HTML-Mail is the first choice to distribute EMail-worms and -virii.
> Back to the roots! 

Bo said the following:
> Michael,
> 
> Thanks for taking a look. I changed the ext int ISR in vxWorks to always set 
> the PIT enable and PIT auto-reload bits (in case the execution of ISR was 
> the first execution after being put to sleep) and got the exact same 
> results. Any ideas?
> 
> You were right that the LED toggler did show up in the "i" command 
> response--under a different name-and as 'READY'--however it was not 
> executing. (???)
> 
For both problems:
make _sure_ that your PIT is getting reenabled on UART-int.
You could do it by attaching an ISR that toggles the LED ;-)
As long as PIT doesn't work properly, scheduling of tasks that are on
taskDelay() won't work anymore. Other tasks pending on semaphores will
work nevertheless.

-- 
Regards,
Mit freundlichen Gr��en,
Michael Lawnick

HTML-Mail is the first choice to distribute EMail-worms and -virii.
Back to the roots!

Paul,

Sleep is also a function of the hardware.  The ppc405 core will signal
that it wishes to be put to sleep with the C405CPMCORESLEEPREQ ouput
signal.  It is the responisbility of external user logic to actually
put the processor to sleep.  This external logic is non-trivial.

The right place to get started is in the UserGuide for the core from
Xilinx:
   http://www.xilinx.com/bvdocs/userguides/ug018.pdf
Look at the last paragraph on page 35.


Regards,
Erik.

---
Erik Widding
President
Birger Engineering, Inc.

 (mail) 100 Boylston St #1070; Boston, MA 02116
(voice) 617.695.9233
  (fax) 617.695.9234
  (web) http://www.birger.com

We discovered the source of our 'cant wake up' problems late Friday.... 
unfortunately, I have not determined how, or even if, the problem can be or 
should be circumvented....

Here's the story of what was/is:


1)We put uP to sleep


2)An ext int happens.


3)The uP wakes up:

   3a)Stores the context, all regs, etc on his ISR context stack-- including 
MSR register.

   3b)We mod the TCR to re-enable timer interrupts

   3c)The ISR is serviced

   3d)The original context is restored.

4)Now, we're back asleep since orig context is restored.


So we're continuously being put back to sleep and our mods to the TCR/MSR 
are promptly overwritten by the ISR context restore at the interrupt exit. 
We tried modifying SRR1 in the ISR to clear the WE bit--but that doesn't 
work. It apparently uses the ISR stack context copy and then restores SRR1 
from the stack, then SRR1 to MSR upon rfi.

I'm looking at how to circumvent it in asm.  Your thoughts?

I understand some VHDL needs to be written for a full implementation of 
power management--but I'm not at all sure how it is all supposed to play 
together. I read about the sleep req and other signals--but I don't follow 
how this comes into play with the level of management I am currently trying 
to get working. The VHDL does make sense to me when you start actually 
physically changing clk freq or disabling clk into the 405 core.  An example 
from Xilinx is apparently too much to hope for... to my and my FAE's 
knowledge there are no CPM examples or std. CPM core--not even for their 
ML310 development boards, but I digress.

As an aside, I cannot seem to find an asm instruction that allows you to 
store the contents of a given register at a desired location (ie offset from 
stack context register R31). In other words, what instruction would I use to 
store contents of R20 at address specified by (R31 + offset)? And the doc 
from Xilinx does not have all instructions that the compiler is generating 
(like "lis").

Paul

"Bo" <bo@cephus.com> wrote in message 
news:Y9nSd.1103$i32.86@fe40.usenetserver.com...
> We discovered the source of our 'cant wake up' problems late Friday.... 
> unfortunately, I have not determined how, or even if, the problem can be 
> or should be circumvented....
>
> Here's the story of what was/is:
>
>
> 1)We put uP to sleep
>
>
> 2)An ext int happens.
>
>
> 3)The uP wakes up:
>
>   3a)Stores the context, all regs, etc on his ISR context stack--  
> including MSR register.
>
>   3b)We mod the TCR to re-enable timer interrupts
>
>   3c)The ISR is serviced
>
>   3d)The original context is restored.
>
> 4)Now, we're back asleep since orig context is restored.
>
>
> So we're continuously being put back to sleep and our mods to the TCR/MSR 
> are promptly overwritten by the ISR context restore at the interrupt exit. 
> We tried modifying SRR1 in the ISR to clear the WE bit--but that doesn't 
> work. It apparently uses the ISR stack context copy and then restores SRR1 
> from the stack, then SRR1 to MSR upon rfi.
>
> I'm looking at how to circumvent it in asm.  Your thoughts?
>
> I understand some VHDL needs to be written for a full implementation of 
> power management--but I'm not at all sure how it is all supposed to play 
> together. I read about the sleep req and other signals--but I don't follow 
> how this comes into play with the level of management I am currently 
> trying to get working. The VHDL does make sense to me when you start 
> actually physically changing clk freq or disabling clk into the 405 core. 
> An example from Xilinx is apparently too much to hope for... to my and my 
> FAE's knowledge there are no CPM examples or std. CPM core--not even for 
> their ML310 development boards, but I digress.
>
> As an aside, I cannot seem to find an asm instruction that allows you to 
> store the contents of a given register at a desired location (ie offset 
> from stack context register R31). In other words, what instruction would I 
> use to store contents of R20 at address specified by (R31 + offset)? And 
> the doc from Xilinx does not have all instructions that the compiler is 
> generating (like "lis").
>
> Paul

I don't pretend to completely comprehend what you found, but I think a "Nice 
Catch" is in order.

I saw in the ppc_ref_guide.pdf that

lis has an equivalent mnemonic addlis page 534.  The user is required to 
skip around this document to look up a simple thing, and it is quite 
annoying.

-Newman