Sign in
Search c6x
Subscribe to c6x
c6x by Keywords
AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560
Ads
Discussion Groups
Discussion Groups | TMS320C6x | Halting the DSP
Technical discussions about the TI C6000 DSPs (including the c62x, c64x and c67x DSPs).
Halting the DSP - an na - Feb 17 6:28:00 2005
|
hi All, Is there any mechanism to Halt the Dsp programatically? i mean can i halt the dsp through my test program ? regards Anoop |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Halting the DSP - George Wicks - Feb 17 10:36:00 2005
|
Yes. There is the IDLE instruction, which effectively halts the CPU until it receives an interrupt (see SPRU189f.pdf, the C6000 CPU and Instruction guide). I suppose if you really want it to stop dead, you'd also want to disable interrupts through the GIE bit. before you call IDLE... I know that this is what you asked for, but are you sure this is what you <want>? George ----- Original Message ----- From: "an na" <> To: <> Sent: Thursday, February 17, 2005 4:28 AM Subject: [c6x] Halting the DSP > > > hi All, > Is there any mechanism to Halt the Dsp programatically? i mean can i halt the dsp through my test program ? > > regards > Anoop |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Halting the DSP - Author Unknown - Feb 18 2:23:00 2005
|
Hi George, Thanks for ur reply. I am kinda confused. What i want to do is to Halt the Processor and then bring it back to bootable state. Yes i had seen the IDLE instruction but wasnt sure whether its the correct way of halting the processor. Can u plz elaborate? regards Anoop > >Yes. There is the IDLE instruction, which effectively halts the CPU until it >receives an >interrupt (see SPRU189f.pdf, the C6000 CPU and Instruction guide). I suppose >if you >really want it to stop dead, you'd also want to disable interrupts through >the GIE bit. >before you call IDLE... > >I know that this is what you asked for, but are you sure this is what you ><want>? > >George > >----- Original Message ----- >From: "an na" <> >To: <> >Sent: Thursday, February 17, 2005 4:28 AM >Subject: [c6x] Halting the DSP >> >> >> hi All, >> Is there any mechanism to Halt the Dsp programatically? i mean >can i halt the dsp through my test program ? >> >> regards >> Anoop >> >> >> >> >> >> >> >> >> >> >> >> >> > |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Bernhard 'Gustl' Bauer - Feb 18 9:39:00 2005
|
Hi Anoop, this sound more like a SW reset. We discussed this some time ago. AFAIR you must write default values to all used peripherals and jump to address 0h. Of course you should block all IRQ via GIE before Idle would be ok if there is nothing to be done and you want to save energy. HTH Gustl wrote: > Hi George, Thanks for ur reply. I am kinda confused. What i want to > do is to Halt the Processor and then bring it back to bootable state. > Yes i had seen the IDLE instruction but wasnt sure whether its the > correct way of halting the processor. Can u plz elaborate? > > regards Anoop > >> >> >> >> >> Yes. There is the IDLE instruction, which effectively halts the CPU >> until it receives an interrupt (see SPRU189f.pdf, the C6000 CPU and >> Instruction guide). I suppose if you really want it to stop dead, >> you'd also want to disable interrupts through the GIE bit. before >> you call IDLE... >> >> I know that this is what you asked for, but are you sure this is >> what you <want>? >> >> George >> >> ----- Original Message ----- From: "an na" <> To: <> Sent: >> Thursday, February 17, 2005 4:28 AM Subject: [c6x] Halting the DSP >> >> >> >> >>> >>> >>> hi All, Is there any mechanism to Halt the Dsp programatically? i >>> mean >> >> can i halt the dsp through my test program ? >> >>> >>> regards Anoop >> |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - George Wicks - Feb 18 12:04:00 2005
|
Hi Anoop, Bernhard: From what you said Anoop, what Bernhard is saying <is> probably what you want to do, i.e., a SW Reset. The CSL functions can easily be used to insure that the processor is in fact brought back to the default conditions at reset, and by jumping to 0x00000000, you're back at the starting gate. That said, there is a legitimate reason for using the IDLE instruction. I've seen a third party RTOS's source code where they use it post-initialization. (Can't go into it, because I'm not at liberty to discuss). The RTOS's task scheduler kicks off the first task on it's task list via the TIMER interrupt (Remember, IDLE effectively Halts the CPU <until> an interrupt is received), thus the CPU is then no longer sitting there in a halted state. No, this wasn't DSP-BIOS, but I'd guess that they probably do what I just mentioned. OK, so what does this all mean? It means that the C6000 processor family is like a "Swiss Army Knife" of DSP procs. There is a large palette of instructions and functions, etc., that you can use and/or abuse. <You> need to decide what it is that is required to do - that drives the coding. You can do a lot of things with the C6000 - the question is what do you really need to do. HTH, George Wicks ----- Original Message ----- From: "Bernhard 'Gustl' Bauer" <> To: <> Cc: <> Sent: Friday, February 18, 2005 7:39 AM Subject: Re: [c6x] Re: Halting the DSP > > > Hi Anoop, > > this sound more like a SW reset. We discussed this some time ago. AFAIR > you must write default values to all used peripherals and jump to > address 0h. Of course you should block all IRQ via GIE before > > Idle would be ok if there is nothing to be done and you want to save > energy. > > HTH > > Gustl > wrote: > > > > > Hi George, Thanks for ur reply. I am kinda confused. What i want to > > do is to Halt the Processor and then bring it back to bootable state. > > Yes i had seen the IDLE instruction but wasnt sure whether its the > > correct way of halting the processor. Can u plz elaborate? > > > > regards Anoop > > > > > > > >> > >> > >> > >> > >> Yes. There is the IDLE instruction, which effectively halts the CPU > >> until it receives an interrupt (see SPRU189f.pdf, the C6000 CPU and > >> Instruction guide). I suppose if you really want it to stop dead, > >> you'd also want to disable interrupts through the GIE bit. before > >> you call IDLE... > >> > >> I know that this is what you asked for, but are you sure this is > >> what you <want>? > >> > >> George > >> > >> ----- Original Message ----- From: "an na" <> To: <> Sent: > >> Thursday, February 17, 2005 4:28 AM Subject: [c6x] Halting the DSP > >> > >> > >> > >> > >>> > >>> > >>> hi All, Is there any mechanism to Halt the Dsp programatically? i > >>> mean > >> > >> can i halt the dsp through my test program ? > >> > >>> > >>> regards Anoop > >> |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Software reset - Marco Braga - Feb 18 13:22:00 2005
|
Hi, I'm interested in SW resetting the DSP. At the moment my procedure is less than perfect. Do you have the code needed to reset every peripherial in a DM642? Or perhaps the link to the related discussion in this ML? Thank you. -- Best regards, Reply to: Marco Braga Insignis Technologies |
|
|
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Software reset - George Wicks - Feb 18 13:55:00 2005
|
Hi Marco: Well, that's a tall order, and I don't have what you're looking for (although it may have been answered before in this group - check to see). Two suggestions: (1). Go through your CSL documentation and find out what calls you need to make to reset all of the peripheral registers, etc., back to the default, then jump to 0x00000000. (2). The other idea, and it's really probably the most ideal if you can do this, is to talk with your HW designer and see about adding a RESET bit to your FPGA or PLD, where if you set it, it outputs an active low RESET to your DM642 - I <believe> (although I can be wrong), all of C6000 chips have an active low RESET. That way, you're actually guaranteed to have your register set back to the default. You've probably already thought of this, but can't have that done because of where you're at in the design cycle, but I thought I'd mention it anyways. Well, hope it helps, George ----- Original Message ----- From: "Marco Braga" <> To: "George Wicks" <> Cc: <> Sent: Friday, February 18, 2005 11:22 AM Subject: Software reset > Hi, > > I'm interested in SW resetting the DSP. At the moment my procedure is > less than perfect. Do you have the code needed to reset every > peripherial in a DM642? Or perhaps the link to the related discussion > in this ML? > Thank you. > > -- > Best regards, Reply to: > Marco Braga > Insignis Technologies |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Mike Dunn - Feb 19 0:39:00 2005
|
Hey folks, I think that you all have covered the bases, but I will chime in anyway with my
opinions.
1. there is no functional reason to halt [or try to halt] a c6000 DSP.
2. you can execute an idle instruction, but if you do you better have a guaranteed
interrupt or you will stay in idle indefinitely. If you are doing this for some form of
error recovery, it would be foolish to count on the DSP timer.
3. if you have "gone into the weeds" and executed "garbage", I suggest a hardware
reset [an external $1-2 [US] micro can be a watchdog]. All of the c6000s that I have
worked with do not seem to have a protected instruction set [if you execute an undefined
instruction, the processor "does something" and does not generate a trap or interrupt].
4. if you look at the possible reasons for a 'reset' [hard or soft] - software
problem, external memory problem, external EMI, power glitch, etc. it does not appear
reasonable to trust the recovery to "a piece of code". The only thing from the above list
that a 'reset function' can recover from is a software problem [as long as it does not clobber
the timer/trigger/I_need_to_reset_indicator or the reset function].
5. I also realize that people may be using their DSP in an environment that I have
not considered and these suggestions may not be appropriate.
Of course, if we all add bullet proof hardware and software, we would not be thinking
about reset after power up.
mikedunn
George Wicks <g...@sbcglobal.net> wrote:
|
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Jeff Brower - Feb 19 12:41:00 2005
|
Mike- > 1. there is no functional reason to halt [or try to halt] a c6000 DSP. Is reducing power consumption a valid reason to make frequent use of IDLE/interrupt combination? . . . > Of course, if we all add bullet proof hardware and software, we would > not be thinking about reset after power up. There is always the cosmic ray with the name of your product on it :-) I know that's truly microscopic writing not yet developed by mankind, but it's there. -Jeff |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Jeff Brower - Feb 19 12:41:00 2005
|
Mike- > 1. there is no functional reason to halt [or try to halt] a c6000 DSP. Is reducing power consumption a valid reason to make frequent use of IDLE/interrupt combination? . . . > Of course, if we all add bullet proof hardware and software, we would > not be thinking about reset after power up. There is always the cosmic ray with the name of your product on it :-) I know that's truly nanoscopic writing not yet developed by mankind, but it's there. -Jeff |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Jeff Brower - Feb 20 2:18:00 2005
|
Hi Bhooshan- > Isnt IDLE like an infinite "branch to itself", if so does it really > help save power? Does TI mention anywhere about power savings due to > IDLE? It does NOPs, which are supposed to save power. Did you know there is a "TMS320C6000 DSP Power-Down Logic and Modes Reference Guide" document? I did not, but there is, seems like it came out in Aug 2004 and was revised Jan 2005: http://focus.ti.com/lit/ug/spru728b/spru728b.pdf On pg 9: "In addition to power-down modes described in this document, the IDLE instruction provides lower CPU power consumption by executing continuous NOPs. The IDLE instruction terminates only upon servicing an interrupt." How much power is saved by hard-coded NOPs vs. a code loop that does the same thing? That's not quantified, but I suppose a bit might be saved by not executing NOPs from P cache, which is a piece of SRAM. -Jeff > On Sat, 19 Feb 2005 10:41:41 -0600, Jeff Brower <> wrote: > > > > Mike- > > > > > 1. there is no functional reason to halt [or try to halt] a c6000 DSP. > > > > Is reducing power consumption a valid reason to make frequent use of IDLE/interrupt > > combination? > > . > > . > > . > > > > > Of course, if we all add bullet proof hardware and software, we would > > > not be thinking about reset after power up. > > > > There is always the cosmic ray with the name of your product on it :-) I know that's > > truly nanoscopic writing not yet developed by mankind, but it's there. > > > > -Jeff > > > > > > > > > > > > > > > > > > -- > ------------------------------------------------------------------- > "I've missed more than 9000 shots in my career. > I've lost almost 300 games. 26 times I've been trusted to take the > game winning shot and missed. > I've failed over and over again in my life. > And that is why I succeed." > -- Michael Jordan > -------------------------------------------------------------------- |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Bhooshan Iyer - Feb 20 2:19:00 2005
|
Jeff-- Isnt IDLE like an infinite "branch to itself", if so does it really help save power? Does TI mention anywhere about power savings due to IDLE? --Bhooshan On Sat, 19 Feb 2005 10:41:41 -0600, Jeff Brower <> wrote: > > Mike- > > > 1. there is no functional reason to halt [or try to halt] a c6000 DSP. > > Is reducing power consumption a valid reason to make frequent use of IDLE/interrupt > combination? > . > . > . > > > Of course, if we all add bullet proof hardware and software, we would > > not be thinking about reset after power up. > > There is always the cosmic ray with the name of your product on it :-) I know that's > truly nanoscopic writing not yet developed by mankind, but it's there. > > -Jeff -- ------------------------------------------------------------------- "I've missed more than 9000 shots in my career. I've lost almost 300 games. 26 times I've been trusted to take the game winning shot and missed. I've failed over and over again in my life. And that is why I succeed." -- Michael Jordan -------------------------------------------------------------------- |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Jeff Brower - Feb 20 21:36:00 2005
|
Jagadeesh- > If the real reason you want to halt the DSP, is to save power, then a better > way to do it would be to use the power down modes. For C67xx devices (I believe the original poster was using DSK C6711), my understanding is the IDLE instruction is the same as writing values to the PWRD field in the CSR that cause PD1 power down mode, and PD2 and PD3 modes are not available. In PD1, the CPU is halted but clock PLL continues to run. My conclusion is that for C67xx devices, a) IDLE instruction is as good as it gets, and b) the benefit is not as much as for other C6xxx devices that support PD2 and PD3. If that's not accurate, please someone correct me. -Jeff > -----Original Message----- > From: Jeff Brower [mailto:] > Sent: Sunday, February 20, 2005 12:18 AM > To: Bhooshan Iyer > Cc: > Subject: Re: [c6x] Re: Halting the DSP > > Hi Bhooshan- > > > Isnt IDLE like an infinite "branch to itself", if so does it really > > help save power? Does TI mention anywhere about power savings due to > > IDLE? > > It does NOPs, which are supposed to save power. Did you know there is a > "TMS320C6000 > DSP Power-Down Logic and Modes Reference Guide" document? I did not, but > there is, > seems like it came out in Aug 2004 and was revised Jan 2005: > > http://focus.ti.com/lit/ug/spru728b/spru728b.pdf > > On pg 9: > > "In addition to power-down modes described in this document, > the IDLE instruction provides lower CPU power consumption > by executing continuous NOPs. The IDLE instruction terminates > only upon servicing an interrupt." > > How much power is saved by hard-coded NOPs vs. a code loop that does the > same thing? > That's not quantified, but I suppose a bit might be saved by not executing > NOPs from > P cache, which is a piece of SRAM. > > -Jeff > > > On Sat, 19 Feb 2005 10:41:41 -0600, Jeff Brower <> > wrote: > > > > > > Mike- > > > > > > > 1. there is no functional reason to halt [or try to halt] a c6000 > DSP. > > > > > > Is reducing power consumption a valid reason to make frequent use of > IDLE/interrupt > > > combination? > > > . > > > . > > > . > > > > > > > Of course, if we all add bullet proof hardware and software, we would > > > > not be thinking about reset after power up. > > > > > > There is always the cosmic ray with the name of your product on it :-) > I know that's > > > truly nanoscopic writing not yet developed by mankind, but it's there. > > > > > > -Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > ------------------------------------------------------------------- > > "I've missed more than 9000 shots in my career. > > I've lost almost 300 games. 26 times I've been trusted to take the > > game winning shot and missed. > > I've failed over and over again in my life. > > And that is why I succeed." > > -- Michael Jordan > > -------------------------------------------------------------------- |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Mike Dunn - Feb 21 0:55:00 2005
|
Jeff,
Jeff Brower <j...@signalogic.com> wrote: Mike- Valid yes, functional no. The
idle instruction can save you power, but I know of any functional reason to use it. Maybe
I am a bit extreme with my meanings... mikedunn
I guess that I should have not been my sarcastic self. For the record, we should always do our best, within our constraints, to develop hardware and software that is immune to as many outside influences as possible. After we have done this, we should assume that the system will fail anyway. At this point we should decide if we have the need and will to recover from such an error... mikedunn
|
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Jeff Brower - Feb 21 9:21:00 2005
|
Mike- > > > 1. there is no functional reason to halt [or try to halt] a c6000 DSP. > > Is reducing power consumption a valid reason to make frequent use of > > IDLE/interrupt combination? > Valid yes, functional no. The idle instruction can save you power, > but I know of any functional reason to use it. Maybe I am a bit > extreme with my meanings... mikedunn If saving power whenever possible is an application objective, what else can be done on the C67xx? I'm not clear on the difference between PD1 mode and IDLE instruction, if any. I'm assuming either one consumes less power than a short code loop that branches to itself and does NOPs, but how much less power? -Jeff |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Jagadeesh Sankaran - Feb 21 11:57:00 2005
|
This seems to match my thinking as well. There have been enhancements by adding PD2 and PD3 specifically for C64xx devices. Regds JS >Jeff Brower wrote: > > Jagadeesh- > > > If the real reason you want to halt the DSP, is to save power, then a better > > way to do it would be to use the power down modes. > > For C67xx devices (I believe the original poster was using DSK C6711), my > understanding is the IDLE instruction is the same as writing values to the PWRD field > in the CSR that cause PD1 power down mode, and PD2 and PD3 modes are not available. > > In PD1, the CPU is halted but clock PLL continues to run. > > My conclusion is that for C67xx devices, a) IDLE instruction is as good as it gets, > and b) the benefit is not as much as for other C6xxx devices that support PD2 and > PD3. > > If that's not accurate, please someone correct me. > > -Jeff > > > -----Original Message----- > > From: Jeff Brower [mailto:] > > Sent: Sunday, February 20, 2005 12:18 AM > > To: Bhooshan Iyer > > Cc: > > Subject: Re: [c6x] Re: Halting the DSP > > > > Hi Bhooshan- > > > > > Isnt IDLE like an infinite "branch to itself", if so does it really > > > help save power? Does TI mention anywhere about power savings due to > > > IDLE? > > > > It does NOPs, which are supposed to save power. Did you know there is a > > "TMS320C6000 > > DSP Power-Down Logic and Modes Reference Guide" document? I did not, but > > there is, > > seems like it came out in Aug 2004 and was revised Jan 2005: > > > > http://focus.ti.com/lit/ug/spru728b/spru728b.pdf > > > > On pg 9: > > > > "In addition to power-down modes described in this document, > > the IDLE instruction provides lower CPU power consumption > > by executing continuous NOPs. The IDLE instruction terminates > > only upon servicing an interrupt." > > > > How much power is saved by hard-coded NOPs vs. a code loop that does the > > same thing? > > That's not quantified, but I suppose a bit might be saved by not executing > > NOPs from > > P cache, which is a piece of SRAM. > > > > -Jeff > > > > > On Sat, 19 Feb 2005 10:41:41 -0600, Jeff Brower <> > > wrote: > > > > > > > > Mike- > > > > > > > > > 1. there is no functional reason to halt [or try to halt] a c6000 > > DSP. > > > > > > > > Is reducing power consumption a valid reason to make frequent use of > > IDLE/interrupt > > > > combination? > > > > . > > > > . > > > > . > > > > > > > > > Of course, if we all add bullet proof hardware and software, we would > > > > > not be thinking about reset after power up. > > > > > > > > There is always the cosmic ray with the name of your product on it :-) > > I know that's > > > > truly nanoscopic writing not yet developed by mankind, but it's there. > > > > > > > > -Jeff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > ------------------------------------------------------------------- > > > "I've missed more than 9000 shots in my career. > > > I've lost almost 300 games. 26 times I've been trusted to take the > > > game winning shot and missed. > > > I've failed over and over again in my life. > > > And that is why I succeed." > > > -- Michael Jordan > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Jeff Brower - Feb 21 18:49:00 2005
|
George- > Hi Anoop, Bernhard: > > From what you said Anoop, what Bernhard is saying <is> probably > what you want to do, i.e., a SW Reset. The CSL functions can easily > be used to insure that the processor is in fact brought back to the > default conditions at reset, and by jumping to 0x00000000, you're > back at the starting gate. > > That said, there is a legitimate reason for using the IDLE instruction. I've > seen a third party RTOS's source code where they use it post-initialization. > (Can't go into it, because I'm not at liberty to discuss). The RTOS's task > scheduler kicks off the first task on it's task list via the TIMER interrupt > (Remember, IDLE effectively Halts the CPU <until> an interrupt is > received), thus the CPU is then no longer sitting there in a halted state. > No, this wasn't DSP-BIOS, but I'd guess that they probably do what I > just mentioned. I hope the 3p makes that a configurable RTOS option. What happens for example if an external processor is using HPI? -Jeff |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - George Wicks - Feb 21 20:14:00 2005
|
Hi Jeff: I don't believe they had a configurable option for it. Though I no longer use it (and I actually don't they are around anymore), but what exactly is the issue with using the IDLE in conjunction with an HPI interface? You've got my curiousity up. - George > George- > I hope the 3p makes that a configurable RTOS option. What happens for example if an > external processor is using HPI? > > -Jeff |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )
Re: Re: Halting the DSP - Jeff Brower - Feb 22 3:09:00 2005
|
George- > I don't believe they had a configurable option for it. Though > I no longer use it (and I actually don't they are around anymore), but what > exactly is the issue with using the IDLE in conjunction with an HPI > interface? You've got my curiousity up. In looking at the "TMS320C6000 DSP Power-Down Logic and Modes Reference Guide" document (SPRU728B) more closely: a) HPI should be Ok with IDLE instruction or PD1 power-down mode b) PD2 and PD3 modes should work Ok on C67xx (what was I thinking before?) c) in PD2 and PD3 modes the document says that "peripheral operation is not assured..." So PD2 and PD3 modes would be the situation where an external processor would need to be aware and avoid using HPI. PD3 completely stops the clock... darn, that sounds good. I need to try that. I wouldn't be surprised if the wake-up interrupt has to be level-triggered in that state, without a clock handy. -Jeff |
(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )