Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
See Also
Discussion Groups | 68HC12 | Strange clock problem
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Strange clock problem - Charles E. Scharlau - Aug 11 7:44:00 2004
|
I'm using an M9S12A64 microprocessor with a Pierce crystal clock circuit running at 4 MHz. I can see a beautiful, clean, stable, 4 MHz clock signal on the EXTAL and XTAL processor pins. Also, I have the /XCLKS pin tied to ground so as to set XCKLS=1 for the Pierce crystal oscillator configuration per the Motorola oscillator block user guide. The VDDPLL and XFC pins are connected to an RC PLL filter circuit copied exactly from the Motorola spec for the M9S12A64. I measure 2.5 volts (clean, no noise or AC) on VDDPLL and XFC pins. All other VDD pins are tied to +5V. VREGEN is also tied to +5V. There is a 100 nF decoupling cap on VDDPLL. All PCB traces are short, and I don't see any significant noise on the +5V rail, or on any of the other signals I look at. Despite everything seeming to be set correctly, when the microprocessor powers up (with program flash entirely blank), it goes directly into self-clock mode (SCM), and never sets the LOCK or TRACK flags in the CRGFLG register. The ECLK pin has a ~1.3 MHz square wave, whereas I would expect a 2.0 MHz square wave were the processor using the 4.0 MHz crystal oscillator. In other words, it is as if the processor (or clock monitor) does not see a valid oscillator clock signal at all, even though I can see one when I scope the pins. Can anyone offer any suggestions as to what the problem might be? |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Strange clock problem - Doron Fael - Aug 11 7:51:00 2004
|
Charles, You write: "All other VDD pins are tied to +5V." Do you also connect the VDD pin to 5V? The VDD pins are 2.5V generated by the internal voltage regulator. VDD must not be connected to +5V as this will probably fry the MC9S12A64. Only VDDX, VDDR, VDDA, VRH and VREGEN should be connected to 5V. Hope this helps, Doron Nohau Corporation HC12 In-Circuit Emulators www.nohau.com/emul12pc.html At 12:44 11/08/2004 +0000, you wrote: >I'm using an M9S12A64 microprocessor with a Pierce crystal clock >circuit running at 4 MHz. I can see a beautiful, clean, stable, 4 MHz >clock signal on the EXTAL and XTAL processor pins. Also, I have >the /XCLKS pin tied to ground so as to set XCKLS=1 for the Pierce >crystal oscillator configuration per the Motorola oscillator block >user guide. The VDDPLL and XFC pins are connected to an RC >PLL filter circuit copied exactly from the Motorola spec for the >M9S12A64. > >I measure 2.5 volts (clean, no noise or AC) on VDDPLL and XFC pins. >All other VDD pins are tied to +5V. VREGEN is also tied to +5V. There >is a 100 nF decoupling cap on VDDPLL. All PCB traces are short, and I >don't see any significant noise on the +5V rail, or on any of the >other signals I look at. > >Despite everything seeming to be set correctly, when the >microprocessor powers up (with program flash entirely blank), it goes >directly into self-clock mode (SCM), and never sets the LOCK or TRACK >flags in the CRGFLG register. The ECLK pin has a ~1.3 MHz square >wave, whereas I would expect a 2.0 MHz square wave were the processor >using the 4.0 MHz crystal oscillator. > >In other words, it is as if the processor (or clock monitor) does not >see a valid oscillator clock signal at all, even though I can see one >when I scope the pins. > >Can anyone offer any suggestions as to what the problem might be? [Non-text portions of this message have been removed] |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Strange clock problem - Charles E. Scharlau - Aug 11 8:24:00 2004
|
To clarify... The following pins are tied to +5V: VDD1* VDD2* VDDR VDDX VDDA VRH VREGEN, is also tied to +5, enabling the on-chip voltage regulator. VDDPLL goes to the PLL filter circuit and measures 2.5V. XFC goes to the PLL filter circuit (opposite side of RC filter) and measures 2.5V. *It looks to me like we should only have bypass caps tied to these pins!! Ouch. Can you confirm that? Another question... Is it normal for XFC to measure a constant 2.5V, or should its value vary with PLL lock voltage (i.e., between 0V < XFC < 2.5V)? I'm guessing that the fact that XFC stays at a constant 2.5V might just be another symptom of the OSC clock not being used by the MCU. Or, might it be normal to always see a constant 2.5V at XFC? --- In , Doron Fael <doronf@n...> wrote: > Charles, > > You write: "All other VDD pins are tied to +5V." > > Do you also connect the VDD pin to 5V? > The VDD pins are 2.5V generated by the internal voltage regulator. VDD must > not be connected to +5V as this will probably fry the MC9S12A64. > > Only VDDX, VDDR, VDDA, VRH and VREGEN should be connected to 5V. > > Hope this helps, > Doron > Nohau Corporation > HC12 In-Circuit Emulators > www.nohau.com/emul12pc.html > > At 12:44 11/08/2004 +0000, you wrote: > >I'm using an M9S12A64 microprocessor with a Pierce crystal clock > >circuit running at 4 MHz. I can see a beautiful, clean, stable, 4 MHz > >clock signal on the EXTAL and XTAL processor pins. Also, I have > >the /XCLKS pin tied to ground so as to set XCKLS=1 for the Pierce > >crystal oscillator configuration per the Motorola oscillator block > >user guide. The VDDPLL and XFC pins are connected to an RC > >PLL filter circuit copied exactly from the Motorola spec for the > >M9S12A64. > > > >I measure 2.5 volts (clean, no noise or AC) on VDDPLL and XFC pins. > >All other VDD pins are tied to +5V. VREGEN is also tied to +5V. There > >is a 100 nF decoupling cap on VDDPLL. All PCB traces are short, and I > >don't see any significant noise on the +5V rail, or on any of the > >other signals I look at. > > > >Despite everything seeming to be set correctly, when the > >microprocessor powers up (with program flash entirely blank), it goes > >directly into self-clock mode (SCM), and never sets the LOCK or TRACK > >flags in the CRGFLG register. The ECLK pin has a ~1.3 MHz square > >wave, whereas I would expect a 2.0 MHz square wave were the processor > >using the 4.0 MHz crystal oscillator. > > > >In other words, it is as if the processor (or clock monitor) does not > >see a valid oscillator clock signal at all, even though I can see one > >when I scope the pins. > > > >Can anyone offer any suggestions as to what the problem might be? > [Non-text portions of this message have been removed] |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: Strange clock problem - Doron Fael - Aug 11 9:41:00 2004
|
Charles, You must disconnect VDD1 and and VDD2 from the +5V. These pins are 2.5V generated by the internal voltage regulator of the MC9S12A64. They need to be connected only to a bypass cap to VSS (to GND). You probably fried the MC9S12A64 part on your board, so after you make cuts on the board to disconnect VDD1 and VDD2 from +5V you will most likely also need to replace the CPU with a fresh MC9S12A64. Hope this helps, Doron Nohau Corporation HC12 In-Circuit Emulators www.nohau.com/emul12pc.html At 13:24 11/08/2004 +0000, you wrote: >To clarify... > >The following pins are tied to +5V: > > VDD1* > VDD2* > VDDR > VDDX > VDDA > VRH > > VREGEN, is also tied to +5, enabling the on-chip voltage regulator. > >VDDPLL goes to the PLL filter circuit and measures 2.5V. >XFC goes to the PLL filter circuit (opposite side of RC filter) and >measures 2.5V. > >*It looks to me like we should only have bypass caps tied to these >pins!! Ouch. Can you confirm that? >Another question... > >Is it normal for XFC to measure a constant 2.5V, or should its value >vary with PLL lock voltage (i.e., between 0V < XFC < 2.5V)? > >I'm guessing that the fact that XFC stays at a constant 2.5V might >just be another symptom of the OSC clock not being used by the MCU. >Or, might it be normal to always see a constant 2.5V at XFC? > >--- In , Doron Fael <doronf@n...> wrote: > > Charles, > > > > You write: "All other VDD pins are tied to +5V." > > > > Do you also connect the VDD pin to 5V? > > The VDD pins are 2.5V generated by the internal voltage regulator. >VDD must > > not be connected to +5V as this will probably fry the MC9S12A64. > > > > Only VDDX, VDDR, VDDA, VRH and VREGEN should be connected to 5V. > > > > Hope this helps, > > Doron > > Nohau Corporation > > HC12 In-Circuit Emulators > > www.nohau.com/emul12pc.html > > > > At 12:44 11/08/2004 +0000, you wrote: > > >I'm using an M9S12A64 microprocessor with a Pierce crystal clock > > >circuit running at 4 MHz. I can see a beautiful, clean, stable, 4 >MHz > > >clock signal on the EXTAL and XTAL processor pins. Also, I have > > >the /XCLKS pin tied to ground so as to set XCKLS=1 for the Pierce > > >crystal oscillator configuration per the Motorola oscillator block > > >user guide. The VDDPLL and XFC pins are connected to an RC > > >PLL filter circuit copied exactly from the Motorola spec for the > > >M9S12A64. > > > > > >I measure 2.5 volts (clean, no noise or AC) on VDDPLL and XFC pins. > > >All other VDD pins are tied to +5V. VREGEN is also tied to +5V. >There > > >is a 100 nF decoupling cap on VDDPLL. All PCB traces are short, >and I > > >don't see any significant noise on the +5V rail, or on any of the > > >other signals I look at. > > > > > >Despite everything seeming to be set correctly, when the > > >microprocessor powers up (with program flash entirely blank), it >goes > > >directly into self-clock mode (SCM), and never sets the LOCK or >TRACK > > >flags in the CRGFLG register. The ECLK pin has a ~1.3 MHz square > > >wave, whereas I would expect a 2.0 MHz square wave were the >processor > > >using the 4.0 MHz crystal oscillator. > > > > > >In other words, it is as if the processor (or clock monitor) does >not > > >see a valid oscillator clock signal at all, even though I can see >one > > >when I scope the pins. > > > > > >Can anyone offer any suggestions as to what the problem might be? > > > > > > [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Re: Strange clock problem - Kevin Antony - Aug 11 9:49:00 2004
|
Yes, VDD1 and VDD2 are bypass pins for the internal regulator. Applying +5V would likely damage the processor. On the XFC pin I usually see a dc offset around 2.5V and the odd positive pulse as the PLL maintains lock. -----Original Message----- From: Charles E. Scharlau [mailto:] Sent: Wednesday, August 11, 2004 7:25 AM To: Subject: [68HC12] Re: Strange clock problem To clarify... The following pins are tied to +5V: VDD1* VDD2* VDDR VDDX VDDA VRH VREGEN, is also tied to +5, enabling the on-chip voltage regulator. VDDPLL goes to the PLL filter circuit and measures 2.5V. XFC goes to the PLL filter circuit (opposite side of RC filter) and measures 2.5V. *It looks to me like we should only have bypass caps tied to these pins!! Ouch. Can you confirm that? Another question... Is it normal for XFC to measure a constant 2.5V, or should its value vary with PLL lock voltage (i.e., between 0V < XFC < 2.5V)? I'm guessing that the fact that XFC stays at a constant 2.5V might just be another symptom of the OSC clock not being used by the MCU. Or, might it be normal to always see a constant 2.5V at XFC? --- In , Doron Fael <doronf@n...> wrote: > Charles, > > You write: "All other VDD pins are tied to +5V." > > Do you also connect the VDD pin to 5V? > The VDD pins are 2.5V generated by the internal voltage regulator. VDD must > not be connected to +5V as this will probably fry the MC9S12A64. > > Only VDDX, VDDR, VDDA, VRH and VREGEN should be connected to 5V. > > Hope this helps, > Doron > Nohau Corporation > HC12 In-Circuit Emulators > www.nohau.com/emul12pc.html > > At 12:44 11/08/2004 +0000, you wrote: > >I'm using an M9S12A64 microprocessor with a Pierce crystal clock > >circuit running at 4 MHz. I can see a beautiful, clean, stable, 4 MHz > >clock signal on the EXTAL and XTAL processor pins. Also, I have > >the /XCLKS pin tied to ground so as to set XCKLS=1 for the Pierce > >crystal oscillator configuration per the Motorola oscillator block > >user guide. The VDDPLL and XFC pins are connected to an RC > >PLL filter circuit copied exactly from the Motorola spec for the > >M9S12A64. > > > >I measure 2.5 volts (clean, no noise or AC) on VDDPLL and XFC pins. > >All other VDD pins are tied to +5V. VREGEN is also tied to +5V. There > >is a 100 nF decoupling cap on VDDPLL. All PCB traces are short, and I > >don't see any significant noise on the +5V rail, or on any of the > >other signals I look at. > > > >Despite everything seeming to be set correctly, when the > >microprocessor powers up (with program flash entirely blank), it goes > >directly into self-clock mode (SCM), and never sets the LOCK or TRACK > >flags in the CRGFLG register. The ECLK pin has a ~1.3 MHz square > >wave, whereas I would expect a 2.0 MHz square wave were the processor > >using the 4.0 MHz crystal oscillator. > > > >In other words, it is as if the processor (or clock monitor) does not > >see a valid oscillator clock signal at all, even though I can see one > >when I scope the pins. > > > >Can anyone offer any suggestions as to what the problem might be? > [Non-text portions of this message have been removed] Yahoo! Groups Sponsor ADVERTISEMENT <http://us.ard.yahoo.com/SIG=1293e8c26/M=298184.5285298.6392945.3001176/D=gr oups/S=1706554205:HM/EXP=1092317162/A=2164330/R=0/SIG=11eamf8g4/*http://www. netflix.com/Default?mqso=60183350> click here <http://us.adserver.yahoo.com/l?M=298184.5285298.6392945.3001176/D=groups/S= :HM/A=2164330/rand=432818136 _____ > . [Non-text portions of this message have been removed] |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Re: Strange clock problem - Peter Lissenburg - Aug 11 9:50:00 2004
|
I did make this mistake on my last PCB :-( But the C32 survived!, so maybe check it before you cut it off. PL At 08:49 AM 11/08/2004 -0600, you wrote: >Yes, VDD1 and VDD2 are bypass pins for the internal regulator. Applying +5V >would likely damage the processor. On the XFC pin I usually see a dc offset >around 2.5V and the odd positive pulse as the PLL maintains lock. > >-----Original Message----- >From: Charles E. Scharlau [mailto:] >Sent: Wednesday, August 11, 2004 7:25 AM >To: >Subject: [68HC12] Re: Strange clock problem >To clarify... > >The following pins are tied to +5V: > > VDD1* > VDD2* > VDDR > VDDX > VDDA > VRH > > VREGEN, is also tied to +5, enabling the on-chip voltage regulator. > >VDDPLL goes to the PLL filter circuit and measures 2.5V. >XFC goes to the PLL filter circuit (opposite side of RC filter) and >measures 2.5V. > >*It looks to me like we should only have bypass caps tied to these >pins!! Ouch. Can you confirm that? >Another question... > >Is it normal for XFC to measure a constant 2.5V, or should its value >vary with PLL lock voltage (i.e., between 0V < XFC < 2.5V)? > >I'm guessing that the fact that XFC stays at a constant 2.5V might >just be another symptom of the OSC clock not being used by the MCU. >Or, might it be normal to always see a constant 2.5V at XFC? > >--- In , Doron Fael <doronf@n...> wrote: > > Charles, > > > > You write: "All other VDD pins are tied to +5V." > > > > Do you also connect the VDD pin to 5V? > > The VDD pins are 2.5V generated by the internal voltage regulator. >VDD must > > not be connected to +5V as this will probably fry the MC9S12A64. > > > > Only VDDX, VDDR, VDDA, VRH and VREGEN should be connected to 5V. > > > > Hope this helps, > > Doron > > Nohau Corporation > > HC12 In-Circuit Emulators > > www.nohau.com/emul12pc.html > > > > At 12:44 11/08/2004 +0000, you wrote: > > >I'm using an M9S12A64 microprocessor with a Pierce crystal clock > > >circuit running at 4 MHz. I can see a beautiful, clean, stable, 4 >MHz > > >clock signal on the EXTAL and XTAL processor pins. Also, I have > > >the /XCLKS pin tied to ground so as to set XCKLS=1 for the Pierce > > >crystal oscillator configuration per the Motorola oscillator block > > >user guide. The VDDPLL and XFC pins are connected to an RC > > >PLL filter circuit copied exactly from the Motorola spec for the > > >M9S12A64. > > > > > >I measure 2.5 volts (clean, no noise or AC) on VDDPLL and XFC pins. > > >All other VDD pins are tied to +5V. VREGEN is also tied to +5V. >There > > >is a 100 nF decoupling cap on VDDPLL. All PCB traces are short, >and I > > >don't see any significant noise on the +5V rail, or on any of the > > >other signals I look at. > > > > > >Despite everything seeming to be set correctly, when the > > >microprocessor powers up (with program flash entirely blank), it >goes > > >directly into self-clock mode (SCM), and never sets the LOCK or >TRACK > > >flags in the CRGFLG register. The ECLK pin has a ~1.3 MHz square > > >wave, whereas I would expect a 2.0 MHz square wave were the >processor > > >using the 4.0 MHz crystal oscillator. > > > > > >In other words, it is as if the processor (or clock monitor) does >not > > >see a valid oscillator clock signal at all, even though I can see >one > > >when I scope the pins. > > > > > >Can anyone offer any suggestions as to what the problem might be? > > > > > > [Non-text portions of this message have been removed] > >Yahoo! Groups Sponsor > >ADVERTISEMENT > ><http://us.ard.yahoo.com/SIG=1293e8c26/M=298184.5285298.6392945.3001176/D=gr >oups/S=1706554205:HM/EXP=1092317162/A=2164330/R=0/SIG=11eamf8g4/*http://www. >netflix.com/Default?mqso=60183350> click here > ><http://us.adserver.yahoo.com/l?M=298184.5285298.6392945.3001176/D=groups/S= >:HM/A=2164330/rand=432818136 > _____ > >> . > > >[Non-text portions of this message have been removed] >Yahoo! Groups Links |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: Strange clock problem - Edward Karpicz - Aug 11 23:42:00 2004
|
From: "Peter Lissenburg" peter@se Sent: Wednesday, August 11, 2004 5:50 PM > I did make this mistake on my last PCB :-( > But the C32 survived!, so maybe check it before you cut it off. > PL My compliments for Motorola/Freescale MCUs. These MCUs tend to survive severe violations of max absolute ratings :-). Conditions like 27V 10W power supply directly applied to output pin (tested with D60ACPV) or 4kV x 100pF 'wired' discharge (68HC11E1) will probably only damage victim pin :-). Damaged D60A continued to work at ~100C in "extreme temperature conditions D60A demo-board". What's an 5V vs 2.5V for Freescale MCU? - Probaly just temporary inconvenience :-). Edward > At 08:49 AM 11/08/2004 -0600, you wrote: > >Yes, VDD1 and VDD2 are bypass pins for the internal regulator. Applying +5V > >would likely damage the processor. On the XFC pin I usually see a dc offset > >around 2.5V and the odd positive pulse as the PLL maintains lock. > > > >-----Original Message----- > >From: Charles E. Scharlau [mailto:] > >Sent: Wednesday, August 11, 2004 7:25 AM > >To: > >Subject: [68HC12] Re: Strange clock problem > > > > > >To clarify... > > > >The following pins are tied to +5V: > > > > VDD1* > > VDD2* > > VDDR > > VDDX > > VDDA > > VRH > > > > VREGEN, is also tied to +5, enabling the on-chip voltage regulator. > > > >VDDPLL goes to the PLL filter circuit and measures 2.5V. > >XFC goes to the PLL filter circuit (opposite side of RC filter) and > >measures 2.5V. > > > >*It looks to me like we should only have bypass caps tied to these > >pins!! Ouch. Can you confirm that? > > > > > >Another question... > > > >Is it normal for XFC to measure a constant 2.5V, or should its value > >vary with PLL lock voltage (i.e., between 0V < XFC < 2.5V)? > > > >I'm guessing that the fact that XFC stays at a constant 2.5V might > >just be another symptom of the OSC clock not being used by the MCU. > >Or, might it be normal to always see a constant 2.5V at XFC? > > > > > > > >--- In , Doron Fael <doronf@n...> wrote: > > > Charles, > > > > > > You write: "All other VDD pins are tied to +5V." > > > > > > Do you also connect the VDD pin to 5V? > > > The VDD pins are 2.5V generated by the internal voltage regulator. > >VDD must > > > not be connected to +5V as this will probably fry the MC9S12A64. > > > > > > Only VDDX, VDDR, VDDA, VRH and VREGEN should be connected to 5V. > > > > > > Hope this helps, > > > Doron > > > Nohau Corporation > > > HC12 In-Circuit Emulators > > > www.nohau.com/emul12pc.html > > > > > > At 12:44 11/08/2004 +0000, you wrote: > > > >I'm using an M9S12A64 microprocessor with a Pierce crystal clock > > > >circuit running at 4 MHz. I can see a beautiful, clean, stable, 4 > >MHz > > > >clock signal on the EXTAL and XTAL processor pins. Also, I have > > > >the /XCLKS pin tied to ground so as to set XCKLS=1 for the Pierce > > > >crystal oscillator configuration per the Motorola oscillator block > > > >user guide. The VDDPLL and XFC pins are connected to an RC > > > >PLL filter circuit copied exactly from the Motorola spec for the > > > >M9S12A64. > > > > > > > >I measure 2.5 volts (clean, no noise or AC) on VDDPLL and XFC pins. > > > >All other VDD pins are tied to +5V. VREGEN is also tied to +5V. > >There > > > >is a 100 nF decoupling cap on VDDPLL. All PCB traces are short, > >and I > > > >don't see any significant noise on the +5V rail, or on any of the > > > >other signals I look at. > > > > > > > >Despite everything seeming to be set correctly, when the > > > >microprocessor powers up (with program flash entirely blank), it > >goes > > > >directly into self-clock mode (SCM), and never sets the LOCK or > >TRACK > > > >flags in the CRGFLG register. The ECLK pin has a ~1.3 MHz square > > > >wave, whereas I would expect a 2.0 MHz square wave were the > >processor > > > >using the 4.0 MHz crystal oscillator. > > > > > > > >In other words, it is as if the processor (or clock monitor) does > >not > > > >see a valid oscillator clock signal at all, even though I can see > >one > > > >when I scope the pins. > > > > > > > >Can anyone offer any suggestions as to what the problem might be? > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > >Yahoo! Groups Sponsor > > > >ADVERTISEMENT > > > ><http://us.ard.yahoo.com/SIG=1293e8c26/M=298184.5285298.6392945.3001176/D=g r > >oups/S=1706554205:HM/EXP=1092317162/A=2164330/R=0/SIG=11eamf8g4/*http://www . > >netflix.com/Default?mqso=60183350> click here > > > ><http://us.adserver.yahoo.com/l?M=298184.5285298.6392945.3001176/D=groups/S = > >:HM/A=2164330/rand=432818136> > > > > > > _____ > > > >> . > > > > > > > > > >[Non-text portions of this message have been removed] > > > > > > > > > > > >Yahoo! Groups Links > > > > > > > > Yahoo! Groups Links |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Strange clock problem - theobee00 - Aug 12 3:39:00 2004
|
--- In , "Edward Karpicz" <karpicz@a...> wrote: > My compliments for Motorola/Freescale MCUs. > These MCUs tend to survive severe violations of max > absolute ratings :-) They do not like 15V on the +5V rail, out of spec it seems, if you do it will also take the BDM along for the ride:-) I have not found an effective protection method yet against such mishaps. Cheers, Theo |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: Strange clock problem - Stephen Trier - Aug 12 9:17:00 2004
|
On Thu, Aug 12, 2004 at 08:39:47AM +0000, theobee00 wrote: > I have not found an effective protection method yet against such mishaps. Put a big 5.6V Zener across Vdd and ground, and hope the fuse blows before the Zener does? Stephen -- Stephen Trier Technical Development Lab Cleveland FES Center |
|
|
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Strange clock problem - Charles E. Scharlau - Aug 12 10:15:00 2004
|
Right now ee're only dealing with four built-up prototypes. At least two of the four appear to have survived the abuse. Another one was spared ever being powered on in the misconfigured state. The fourth one might be having issues not related to the abuse. So we're happy. Ways to avoid this problem? We could have had more careful and systematic reviews of our schematics. I find it interesting that mis-wiring the digital VDD lines only appears to have affected the clock monitor. (Of course we might have discovered other problems had we looked further.) But, if the MCU had actually shut down completely (or had given up some magic smoke), we probably would have found our problem more quickly, since we would have broadened our search beyond just the clock-related components much sooner. Anyway, thanks to everyone who responded; especially Doron. This forum has been a big help, and I've only been a member for less than 48 hours. Best Regards The processor appears t --- In , Peter Lissenburg <peter@s...> wrote: > I did make this mistake on my last PCB :-( > But the C32 survived!, so maybe check it before you cut it off. > PL > > At 08:49 AM 11/08/2004 -0600, you wrote: > >Yes, VDD1 and VDD2 are bypass pins for the internal regulator. Applying +5V > >would likely damage the processor. On the XFC pin I usually see a dc offset > >around 2.5V and the odd positive pulse as the PLL maintains lock. > > > >-----Original Message----- > >From: Charles E. Scharlau [mailto:cscharlau@e...] > >Sent: Wednesday, August 11, 2004 7:25 AM > >To: > >Subject: [68HC12] Re: Strange clock problem > > > > > >To clarify... > > > >The following pins are tied to +5V: > > > > VDD1* > > VDD2* > > VDDR > > VDDX > > VDDA > > VRH > > > > VREGEN, is also tied to +5, enabling the on-chip voltage regulator. > > > >VDDPLL goes to the PLL filter circuit and measures 2.5V. > >XFC goes to the PLL filter circuit (opposite side of RC filter) and > >measures 2.5V. > > > >*It looks to me like we should only have bypass caps tied to these > >pins!! Ouch. Can you confirm that? > > > > > >Another question... > > > >Is it normal for XFC to measure a constant 2.5V, or should its value > >vary with PLL lock voltage (i.e., between 0V < XFC < 2.5V)? > > > >I'm guessing that the fact that XFC stays at a constant 2.5V might > >just be another symptom of the OSC clock not being used by the MCU. > >Or, might it be normal to always see a constant 2.5V at XFC? > > > > > > > >--- In , Doron Fael <doronf@n...> wrote: > > > Charles, > > > > > > You write: "All other VDD pins are tied to +5V." > > > > > > Do you also connect the VDD pin to 5V? > > > The VDD pins are 2.5V generated by the internal voltage regulator. > >VDD must > > > not be connected to +5V as this will probably fry the MC9S12A64. > > > > > > Only VDDX, VDDR, VDDA, VRH and VREGEN should be connected to 5V. > > > > > > Hope this helps, > > > Doron > > > Nohau Corporation > > > HC12 In-Circuit Emulators > > > www.nohau.com/emul12pc.html > > > > > > At 12:44 11/08/2004 +0000, you wrote: > > > >I'm using an M9S12A64 microprocessor with a Pierce crystal clock > > > >circuit running at 4 MHz. I can see a beautiful, clean, stable, 4 > >MHz > > > >clock signal on the EXTAL and XTAL processor pins. Also, I have > > > >the /XCLKS pin tied to ground so as to set XCKLS=1 for the Pierce > > > >crystal oscillator configuration per the Motorola oscillator block > > > >user guide. The VDDPLL and XFC pins are connected to an RC > > > >PLL filter circuit copied exactly from the Motorola spec for the > > > >M9S12A64. > > > > > > > >I measure 2.5 volts (clean, no noise or AC) on VDDPLL and XFC pins. > > > >All other VDD pins are tied to +5V. VREGEN is also tied to +5V. > >There > > > >is a 100 nF decoupling cap on VDDPLL. All PCB traces are short, > >and I > > > >don't see any significant noise on the +5V rail, or on any of the > > > >other signals I look at. > > > > > > > >Despite everything seeming to be set correctly, when the > > > >microprocessor powers up (with program flash entirely blank), it > >goes > > > >directly into self-clock mode (SCM), and never sets the LOCK or > >TRACK > > > >flags in the CRGFLG register. The ECLK pin has a ~1.3 MHz square > > > >wave, whereas I would expect a 2.0 MHz square wave were the > >processor > > > >using the 4.0 MHz crystal oscillator. > > > > > > > >In other words, it is as if the processor (or clock monitor) does > >not > > > >see a valid oscillator clock signal at all, even though I can see > >one > > > >when I scope the pins. > > > > > > > >Can anyone offer any suggestions as to what the problem might be? > > > > > > > > > [Non-text portions of this message have been removed] > > > > > > > >Yahoo! Groups Sponsor > > > >ADVERTISEMENT > > > ><http://us.ard.yahoo.com/SIG=1293e8c26/M=298184.5285298.6392945.30011 76/D=gr > >oups/S=1706554205:HM/EXP=1092317162/A=2164330/R=0/SIG=11eamf8g4/*http ://www. > >netflix.com/Default?mqso=60183350> click here > > > ><http://us.adserver.yahoo.com/l? M=298184.5285298.6392945.3001176/D=groups/S= > >:HM/A=2164330/rand=432818136> > > > > > > _____ > > > >> . > > > > > > > > > >[Non-text portions of this message have been removed] > > > > > > > > > > > >Yahoo! Groups Links > > > > > > > |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Strange clock problem - theobee00 - Aug 12 15:18:00 2004
|
--- In , "Stephen Trier" <sct@p...> wrote: Hi Stephen, > > I have not found an effective protection method yet against such mishaps. > > Put a big 5.6V Zener across Vdd and ground, and hope the fuse blows > before the Zener does? The problem is that the supply is capable of several amps, not needed but a byproduct of the current needed for the 15V lines, the only way would be some type of combination SCR and diode protection. The problem is that to put it on the production units would be far too expensive for the odd occasion they mix up the wiring to the supply. If I modify the Pod it likely would just burn out the Pod cabling and the tracks. I have put an extra stage of inspection in, experience over ten years with this method is that it works for a few months/years until it gets forgotten as a useless activity, nothing ever happens etc. But the old units just blew the chips, they didn't have a compod attached... Look around for an easily repairable type of POD or serial programming method seems to be the current answer:-) Cheers, Theo |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: Strange clock problem - Author Unknown - Aug 12 15:27:00 2004
|
If you use a small instrument fuse in series with the external supply line, as well as the zener, the fuse will clear without slagging the zener. These fuses are available at quite reasonable prices, and do a pretty good job of keeping the smoke in. Jim At 04:18 PM 8/12/2004, you wrote: >--- In , "Stephen Trier" <sct@p...> wrote: > >Hi Stephen, > > > > I have not found an effective protection method yet against such mishaps. > > > > Put a big 5.6V Zener across Vdd and ground, and hope the fuse blows > > before the Zener does? > >The problem is that the supply is capable of several amps, not needed but >a byproduct of the current needed for the 15V lines, the only way would be >some type of combination SCR and diode protection. > >The problem is that to put it on the production units would be far too >expensive for the odd occasion they mix up the wiring to the supply. > >If I modify the Pod it likely would just burn out the Pod cabling and the >tracks. > >I have put an extra stage of inspection in, experience over ten years with >this method is that it works for a few months/years until it gets >forgotten as a useless activity, nothing ever happens etc. > >But the old units just blew the chips, they didn't have a compod attached... > >Look around for an easily repairable type of POD or serial programming >method seems to be the current answer:-) > >Cheers, > >Theo >Yahoo! Groups Links |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Re: Strange clock problem - Author Unknown - Aug 13 5:15:00 2004
|
Better than a fuse, because you have to change it if it's blow : Polyswitches (made by Raychem or others...), that means the fuse automaticaly rearms when the defect stops. Automotive use that kind of fuse for motor for glasses. I use them in my systems, and it's very interesting. In France : Farnell or Radiospares. In other countries ? Joel -----Message d'origine----- De : [mailto:] Envoyé : jeudi 12 août 2004 22:28 À : Objet : Re: [68HC12] Re: Strange clock problem If you use a small instrument fuse in series with the external supply line, as well as the zener, the fuse will clear without slagging the zener. These fuses are available at quite reasonable prices, and do a pretty good job of keeping the smoke in. Jim At 04:18 PM 8/12/2004, you wrote: >--- In , "Stephen Trier" <sct@p...> wrote: > >Hi Stephen, > > > > I have not found an effective protection method yet against such mishaps. > > > > Put a big 5.6V Zener across Vdd and ground, and hope the fuse blows > > before the Zener does? > >The problem is that the supply is capable of several amps, not needed >but a byproduct of the current needed for the 15V lines, the only way >would be some type of combination SCR and diode protection. > >The problem is that to put it on the production units would be far too >expensive for the odd occasion they mix up the wiring to the supply. > >If I modify the Pod it likely would just burn out the Pod cabling and >the tracks. > >I have put an extra stage of inspection in, experience over ten years >with this method is that it works for a few months/years until it gets >forgotten as a useless activity, nothing ever happens etc. > >But the old units just blew the chips, they didn't have a compod attached... > >Look around for an easily repairable type of POD or serial programming >method seems to be the current answer:-) > >Cheers, > >Theo |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: Strange clock problem - Bob Smith - Aug 13 5:44:00 2004
|
Better than a fuse, because you have to change it if it's blow : Polyswitches (made by Raychem or others...), that means the fuse automaticaly rearms when the defect stops. Yes. I have, for many years, used a Raychem Polyfuse and a 5.6 V Zener to protect my embedded controllers with complete success. Use one of the big (usually glass) Zeners with the big silver leads and a generous solder pad to soak up the heat. They will take an enormous amount of abuse. Automotive use that kind of fuse for motor for glasses. Well Mercedes doesn't. My 300E type has some kind of thermal fuse that you can see (and hear) click on and off when a window switch sticks. Boooooo! So much for Mercedes "superb" engineering!!! I use them in my systems, and it's very interesting. In France : Farnell or Radiospares. In other countries ? In the U.S. get them at http://www.digikey.com Best wishes, Bob Smith --- Avoid computer viruses, Practice safe hex --- -- Specializing in small, cost effective embedded control systems -- http://www.smithmachineworks.com/embedprod.html Robert L. (Bob) Smith Smith Machine Works, Inc. 9900 Lumlay Road Richmond, VA 23236 804/745-2608 ----- Original Message ----- From: <> To: <> Sent: Friday, August 13, 2004 6:15 AM Subject: RE: [68HC12] Re: Strange clock problem Better than a fuse, because you have to change it if it's blow : Polyswitches (made by Raychem or others...), that means the fuse automaticaly rearms when the defect stops. Automotive use that kind of fuse for motor for glasses. I use them in my systems, and it's very interesting. In France : Farnell or Radiospares. In other countries ? Joel -----Message d'origine----- De : [mailto:] Envoyé : jeudi 12 août 2004 22:28 À : Objet : Re: [68HC12] Re: Strange clock problem If you use a small instrument fuse in series with the external supply line, as well as the zener, the fuse will clear without slagging the zener. These fuses are available at quite reasonable prices, and do a pretty good job of keeping the smoke in. Jim At 04:18 PM 8/12/2004, you wrote: >--- In , "Stephen Trier" <sct@p...> wrote: > >Hi Stephen, > > > > I have not found an effective protection method yet against such mishaps. > > > > Put a big 5.6V Zener across Vdd and ground, and hope the fuse blows > > before the Zener does? > >The problem is that the supply is capable of several amps, not needed >but a byproduct of the current needed for the 15V lines, the only way >would be some type of combination SCR and diode protection. > >The problem is that to put it on the production units would be far too >expensive for the odd occasion they mix up the wiring to the supply. > >If I modify the Pod it likely would just burn out the Pod cabling and >the tracks. > >I have put an extra stage of inspection in, experience over ten years >with this method is that it works for a few months/years until it gets >forgotten as a useless activity, nothing ever happens etc. > >But the old units just blew the chips, they didn't have a compod attached... > >Look around for an easily repairable type of POD or serial programming >method seems to be the current answer:-) > >Cheers, > >Theo Yahoo! Groups Sponsor ADVERTISEMENT ---------------------------------------------------------------------------- ---- Yahoo! Groups Links a.. To |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
[ANN] CW12 V3.1 B128 Service Pack - MW Ron - Aug 13 9:57:00 2004
|
CW12 V3.1 B128 Service Pack Release date: 8/9/2004 The CW12_V3_1_B128_SP service pack provides assembly, C, and C++ stationery for the MC9S12B128 and MC9S12B64. Each stationery provides C headers files, assembly include files, parameter files and flash programming algorithms to create a CodeWarrior project for MC9S12Bxxx microcontrollers. The stationery provide support for the following target connections: € Metrowerks Simulator € HCS12 Serial Monitor € Cyclone Pro € Parallel port BDM-Multilink € USB Multilink The use of the Cyclone Pro, Parallel port BDM-Multilink or the USB HCS12 Multilink interface is fully supported on the following operating Microsoft systems: Windows 98, Windows 2000 and Windows XP. |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
[ANN] CW12 V3.1 C128 Service Pack - MW Ron - Aug 13 9:58:00 2004
|
CW12 V3.1 C128 Service Pack Release date: 8/9/2004 The CW12_V3_1_C128_SP service pack provides assembly, C, and C++ stationery for the MC9S12C128, MC9S12C96 and MC9S12C64. Each stationery provides C headers files, assembly include files, parameter files and flash programming algorithms to create a CodeWarrior project for MC9S12Cxxx microcontrollers. The stationery provides support for the following target connections: € Metrowerks Simulator € HCS12 Serial Monitor € Cyclone Pro € Parallel port BDM-Multilink € USB Multilink The use of the Cyclone Pro, Parallel port BDM-Multilink or the USB HCS12 Multilink interface is fully supported on the following operating Microsoft systems: Windows 98, Windows 2000 and Windows XP. |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
[ANN] HCS12 Processor Expert Update for CodeWarrior for HCS12 v3.1 - MW Ron - Aug 13 9:59:00 2004
|
HCS12 Processor Expert Update for CodeWarrior Development Studio for HCS12 Microcontrollers, Version 3.1 Release date: 8/9/2004 The HC12 Processor Expert Service Pack updates Processor Expert to V2.94. This release updates the header, source and assembly include files for the following HCS12 derivatives: -- Metrowerks Community Forum is a free online resource for developers to discuss CodeWarrior topics with other users and Metrowerks' staff -- http://www.metrowerks.com/community -- Ron Liechty - - http://www.metrowerks.com |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Re: Strange clock problem - Allen, Nick - Aug 16 11:41:00 2004
|
VERY short duration Nick > -----Original Message----- > From: Darrell N. [mailto:] > Sent: Monday, August 16, 2004 1:40 PM > To: > Subject: RE: [68HC12] Re: Strange clock problem > > > > I would concur with the polyfuse technique. We have also used it > > for years with success both on 5V and 24V rails. The only > > variation on the theme is that the zener is replaced with a 5V1 > > transil rated at 1.5KW. > > That must be one helluva zener, at 1.5 kW. Isn't it hard to fit > that onto a circuit board? > > > Regards, > Darrell Norquay > > Datalog Technology Inc. Calgary, Alberta, Canada > Voice: (403) 243-2220 Fax: (403) 243-2872 > Email: Web: www.datalog.ab.ca > > ------------------------ Yahoo! Groups Sponsor > --------------------~--> > Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar. > Now with Pop-Up Blocker. Get it for free! > http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dN_tlB/TM > -------------------------------------------------------------- > ------~- > Yahoo! Groups Links |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )