1. Home
  2. Field-Programmable Gate Arrays
  3. PPC405 sleep?

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

Reply to
Bo
Loading thread data ...

Bo said the following:

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.

How should it? You disabled timer interrupt!

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 to
Michael Lawnick

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

Reply to
Bo

Bo said the following:

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 to
Michael Lawnick

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:

formatting link
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 to
Erik Widding

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 to
Bo

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 to
newman5382

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.