"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
Reply by Bo●February 21, 20052005-02-21
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
Reply by Erik Widding●February 17, 20052005-02-17
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
Reply by Michael Lawnick●February 17, 20052005-02-17
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!
Reply by Bo●February 17, 20052005-02-17
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��en,
> Michael Lawnick
>
> HTML-Mail is the first choice to distribute EMail-worms and -virii.
> Back to the roots!
Reply by Michael Lawnick●February 17, 20052005-02-17
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!
Reply by Bo●February 16, 20052005-02-16
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