That's what I was wondering as well. Since you need an external crystal anyway to stabalize the DCO (especially when trying to run above 4Mhz) then why wouldn't you want to use the same crystal as the base time source. 32Khz crystals are cheap anyways because they are used so much. Having TimerA interrupts constantly chugging along (in LPM3)at some slow rate (100-1000Hz) makes time based software so easy to write. If you tried to use the DCO with this High-Speed/Low-Speed method you would have to be constantly changing your divisors for your periodic timers. The whole idea sounds like driving in traffic (speed up, slow down, speed up, slow down). Unless your high-speed needs came along infrequently then you'd be spending alot of time just changing modes. And unless you actually used the extra processing power while in that mode then you would have used more power to get there then you actually used (so chugging along at a lower speed that doesn't have to be stabilized might actually get done faster). This processor is far to useful with it's many modes of operations, timers, and methods for using them that any attempt at creating "standard" configurations will fail (or just be inefficent in the same way that most RTOS are.) --- In msp430@y..., "Bruce Cannon" <brucecannon@a...> wrote: > > The low freq crystal is not a requirement. The CPU can be clocked only by the DCO if desired. > > The absolute lowest operating current can be achieved using the DCO and having the low frequency > > oscillator turned off. > > How exactly is this achieved? Isn't the nominal low end of the DCO frequency ~100kHz with internal > resistor, and doesn't this require significantly more current than the 32k osc? Is the writer > referring to an undocumented lowest external resistor value, or a periodic external wake, with DCO > off at other times? > > > On devices other than the F4xx series, there is no fault detect for a failing crystal in the > > low freq. osc. However, the clock will default to the DCO. > > Does this imply that although there is no fault flag in smaller parts, software can still easily > determine fault by verifying the osc source? > > Bruce
MCLK output
Started by ●June 28, 2002
Reply by ●July 26, 20022002-07-26
Reply by ●July 30, 20022002-07-30
Bruce,
I received the following
response from a TI contact. The response is in blue.
Clyde
Eisenbeis
---------------------------------
> The absolute lowest operating current can be achieved using the DCO and having the low frequency
> oscillator turned off.
How exactly is this achieved? Isn't the nominal low end of the DCO frequency ~100kHz with internal
resistor, and doesn't this require significantly more current than the 32k osc? Is the writer
referring to an undocumented lowest external resistor value, or a periodic external wake, with DCO
off at other times?
The LFXT1
oscillator can be disabled by setting CPUOFF in the status registers. The DCO
can then be used to provide the processor clock (from 100KHz to approx. 5MHz
[when using the on-board Rdco]).
One needs to
differentiate between instantaneous current and the total system current
required to "get the job done". In most MSP430 applications, the
lowest system current requirement is achieved by having the CPU in a low
power sleep mode for as long as possible (with CPU and DCO off), and then waking
up in response to a system condition, servicing the
condition with the CPU running as fast as possible (from the DCO), and then
going back to sleep. If the speed of the CPU does not need to be
calibrated, the 32KHz reference frequency provided by LFXT1 can be
disabled, and this saves additional current. If the CPU speed needs to be
calibrated, use the LFXT1 as a reference. Since the LFXT1 uses very little
current and since it requires a significant start-up time, it's recommended
to leave the LFXT1 oscillator running whenever ACLK might be needed. *** Do not
clock the CPU at 32KHz; this will not result in the lowest system current;
instantaneous current may be low, but the total time required to get the job
done will be dramatically greater. And this fact will result is a greater
overall system current consumption. ***.
> On devices other than the F4xx series, there is no fault detect for a failing crystal in the
> low freq. osc. However, the clock will default to the DCO.
Does this imply that although there is no fault flag in smaller parts, software can still easily
determine fault by verifying the osc source?
> On devices other than the F4xx series, there is no fault detect for a failing crystal in the
> low freq. osc. However, the clock will default to the DCO.
Does this imply that although there is no fault flag in smaller parts, software can still easily
determine fault by verifying the osc source?
My previous
answer was not completely correct. Perhaps a more complete answer would
be:
On devices
other than the F4xx series, there is no fault detect for a failing crystal in
the low freq. osc. *** when it is operating in low frequency crystal mode. There
is a fault detect signal if a high frequency crystal fails to start when
the oscillator is in high frequency crystal mode. *** However, the CPU clock
(MCLK) will default to the DCO [if there is an oscillator
fault]".
One can use
software to determine if the low frequency oscillator/crystal has failed; simply
run the CPU off of the DCO, and clock a timer with ACLK. If the timer does not
increment as expected, your crystal is dead.
Please refer
to the LFXT1 and XT2 Oscillator section of the Basic Clock Module chapter of the
User's Guide for a detailed description of the operation of the MSP430
oscillators.
Reply by ●July 30, 20022002-07-30
Clyde:
Thanks for the response.
To further clarify, I believe they are saying, in the first (DCO)
subject, that IF your design has a means of waking the system when needed, then
a DCO-only design will have the lowest current cost. This was the point
that I tried to make last time, that if you eliminate the 32k osc (and the
implied periodic Timer_A interrupt) then in order to function you must
provide some external method for periodically waking the system. If one
were needing some peripheral tasks anyway, then this is not a problem, you could
have the ADC completion et al wake the system instead of the 32k osc. But
in general I suspect the statement "DCO-only is lowest current method" is
misleading.
In the second (fault detection) subject, I think they are saying that
the LF osc has no fault flag but that the system will switch to the DCO if
the LF osc fails. So in an app where one expects to be woken periodically
by Timer_A clocked by the LF osc, one could on each wake check to see if the
period has in fact elapsed. I also wonder if the osc configuration bits
are set by the system when it switches to the DCO (after the LF osc
stops). If not, this could be used too (if the system is running on the
DCO while it is supposed to be running off the LF osc then fault). But I
imagine they are.
Bruce
-----Original Message-----
From: Eisenbeis, Clyde [FRCO/MTN] [mailto:clyde.eisenbeis@emersonprocess.com]
Sent: Tuesday, July 30, 2002 5:31 AM
To: 'msp430@yahoogroups.com'
Subject: RE: [msp430] Re: MCLK outputBruce,I received the following response from a TI contact. The response is in blue.Clyde Eisenbeis---------------------------------> The low freq crystal is not a requirement. The CPU can be clocked only by the DCO if desired.
> The absolute lowest operating current can be achieved using the DCO and having the low frequency
> oscillator turned off.
How exactly is this achieved? Isn't the nominal low end of the DCO frequency ~100kHz with internal
resistor, and doesn't this require significantly more current than the 32k osc? Is the writer
referring to an undocumented lowest external resistor value, or a periodic external wake, with DCO
off at other times?The LFXT1 oscillator can be disabled by setting CPUOFF in the status registers. The DCO can then be used to provide the processor clock (from 100KHz to approx. 5MHz [when using the on-board Rdco]).One needs to differentiate between instantaneous current and the total system current required to "get the job done". In most MSP430 applications, the lowest system current requirement is achieved by having the CPU in a low power sleep mode for as long as possible (with CPU and DCO off), and then waking up in response to a system condition, servicing the condition with the CPU running as fast as possible (from the DCO), and then going back to sleep. If the speed of the CPU does not need to be calibrated, the 32KHz reference frequency provided by LFXT1 can be disabled, and this saves additional current. If the CPU speed needs to be calibrated, use the LFXT1 as a reference. Since the LFXT1 uses very little current and since it requires a significant start-up time, it's recommended to leave the LFXT1 oscillator running whenever ACLK might be needed. *** Do not clock the CPU at 32KHz; this will not result in the lowest system current; instantaneous current may be low, but the total time required to get the job done will be dramatically greater. And this fact will result is a greater overall system current consumption. ***.
> On devices other than the F4xx series, there is no fault detect for a failing crystal in the
> low freq. osc. However, the clock will default to the DCO.
Does this imply that although there is no fault flag in smaller parts, software can still easily
determine fault by verifying the osc source?My previous answer was not completely correct. Perhaps a more complete answer would be:On devices other than the F4xx series, there is no fault detect for a failing crystal in the low freq. osc. *** when it is operating in low frequency crystal mode. There is a fault detect signal if a high frequency crystal fails to start when the oscillator is in high frequency crystal mode. *** However, the CPU clock (MCLK) will default to the DCO [if there is an oscillator fault]".One can use software to determine if the low frequency oscillator/crystal has failed; simply run the CPU off of the DCO, and clock a timer with ACLK. If the timer does not increment as expected, your crystal is dead.Please refer to the LFXT1 and XT2 Oscillator section of the Basic Clock Module chapter of the User's Guide for a detailed description of the operation of the MSP430 oscillators.
">Yahoo! Terms of Service.
Reply by ●August 1, 20022002-08-01
Hi Clyde et all,
I've been off the air for a bit, been unwell.
> The code above is *not* the recommended way to
start-up the osc. into a high freq. mode and switch over the MCLK to
it.
Other users seem to have pointed out this too.
In the early days, TI themselves used a similar code setup. I should have
kept up ..... !
I think the reason I've never really had any problems this way is
because I always has XT2 running
@ 6-8 MHz, not sure.
(And I waited an extra 500-800 mS or so for LFXTAL1 @ 32.768 kHz....)
I stand corrected, and will keep it in mind myself.
Again, there's always something to learn !!!!
Kris
Reply by ●December 4, 20032003-12-04
Hello Kris I'll appreciate it very much if you would shed some light on the subject of Crystal's ESR for the MSP430F133. In the T.I. web site KnowledegeBase-Case 32069 it states, "high frequency crystals don't have the ESR < 40 Ohm limitation". I consider an 8MHz crystal high frequency as far as the MSP430 is concerned. Does this mean that the 8MHz crystal can have any ESR, but the oscillator may start up faster or be more stable if I use a crystal with ESR < 40 Ohms? --- In msp430@msp4..., "Kris De Vos" <microbit@c...> wrote: > Hi Clyde, > > A few pointers : > > 1. When you use a "high frequency" crystal on LFXTAL1 (XT1) you have to set the XTS bit in BCSCTL1. > 2. You have to account for the oscillator fault circuitry. > If the clock fails, the CPU would enter an irrecoverable state. Conversely, on startup the MSP430 defaults to the DCO. > 3. If you switch to XT2 for MCLK, the OFIFG flag is still set (after power up the crystal oscillators aren't running yet, the DCO > is however) - So the CPU will straight away switch back to DCO as its MCLK, because it thimks there's still an OSC fault > > You first need to clear OFIFG before switching clock. > > The best sequence to switch from DCO to XT2 for MCLK is : > > /* either wait enough time for XT2 ( + opt XT1) to settle */ > // wait XXX mS clocked with the DCO ........... > > OR > > do (IFG1 &=~OFIFG) > while (IFG1&OFIFG); /* wait till oscillator(s) have stabilised...... > > AND/OR NOW > > IFG1&=~OFIFG; /* case just used delay, clear the oscillator fault flag */ > BCSCTL1 &= ~XT2OFF; /* now swicth your clock from DCO -> XT2 */ > BCSCTL2 |= SELM_2; > > That'll work 100% for you. > > PS : > OFIFG flag clearing means that the XT2 has been running for (I think) 100 consecutive cycles without fault. > It does not mean its frequency is accurate. (as a rule of fist, it takes Q cycles to stabilise) > As a rough guide, depending on crystal ESR (low profile HC49 has higher ESR) it takes ~ 5-6 mS to stabilise > an 6 MHz crystal on XT2. > It also depends on the phase shift network (loading caps) and the loading capacitance of your crystal. > I wouldn't worry too much about the 64 vs. 68 pF caps, you crystal probably has different characteristics anyway. > > > Kris > > > > ----- Original Message ----- > From: Eisenbeis, Clyde [FRCO/MTN] > To: 'msp430@'msp...' > Sent: Tuesday, July 02, 2002 7:41 AM > Subject: RE: [msp430] Re: MCLK output > > > Thanks Peter ... I have it straight now. > > In the docs, my sense is that slow freq crystals should use Xin and high freq crystals should use Xt2in. Yet the fet140_clks.s43 uses a high freq crystal on Xin. Is there any advantage of using Xin over Xt2in (assuming I don't need an ACLK)? > > I stuck a 1Mhz crystal across Xt2in with a couple of 68pf caps (did not have any 64pf caps). The crystal appears to be oscillating ok, but I can't get anything out of MCLK except for the DCO. The instructions I am using to switch MCLK to Xt2clk are: > > BCSCTL1 &= ~XT2OFF; > BCSCTL2 |= SELM_2; > > Any suggestions? > > Clyde > > > -----Original Message----- > From: Forstner, Peter [mailto:msp430@o...] > Sent: Monday, July 01, 2002 9:31 AM > To: 'msp430@'msp...' > Subject: RE: [msp430] Re: MCLK output > > > Clyde, > An example is at TI's web site http://www.ti.com/sc/msp430 >>> Code Examples > > MSP-FET430P140 Assembler Examples slac014x.zip (38k) > a.. fet140_clks.s43 - BasicClock Output buffered SMCLK, ACLK and MCLK > Regards > Peter > > -----Original Message----- > From: Eisenbeis, Clyde [FRCO/MTN] [mailto:clyde.eisenbeis@e...] > Sent: Monday, 01 July, 2002 15:43 > To: 'msp430@'msp...' > Subject: RE: [msp430] Re: MCLK output > > > Thanks Chris. Made the change ... still no MCLK. I'm quite confident the code is downloading and running properly ... I modified the blinking LED sample code (fet140_1.c) ... the LED blinks, but still no MCLK. > -----Original Message----- > From: dellaenterprises [mailto:dellaenterprises@p...] > Sent: Friday, June 28, 2002 5:47 PM > To: msp430@msp4... > Subject: [msp430] Re: MCLK output > > > --- In msp430@y..., "cteise" <clyde.eisenbeis@e...> wrote: > > I am unable to see any output from MCLK (pin 48 on an Msp- > > fet430p140). I tried to set P5 to be an output ... P5 0x0F, but > > still see no MCLK. Any ideas? > > You must also set same bit in the P5SEL register to change the output > of the pin from a standard I/O to its "alternate function", i.e. > output of the MCLK. > Chris > > > . > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > > . > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > . > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > > > > > . > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Reply by ●December 4, 20032003-12-04
Hi All, Here is T.I. application engineer response to my question: Leonard, The FAQ that you mentioned from the KnowledgeBase is incorrect and is being pulled to be corrected. No, the 8MHz crystal can't have any ESR. The ESR should be <40k ohms for HF crystals. Regards, Tresha Jackson Analog and Mixed Signal Product Specialist --- In msp430@msp4..., "braunlen" <lbraun@n...> wrote: > Hello Kris > > I'll appreciate it very much if you would shed some light on the > subject of Crystal's ESR for the MSP430F133. > > In the T.I. web site KnowledegeBase-Case 32069 it states, "high > frequency crystals don't have the ESR < 40 Ohm limitation". > > I consider an 8MHz crystal high frequency as far as the MSP430 is > concerned. > Does this mean that the 8MHz crystal can have any ESR, but the > oscillator may start up faster or be more stable if I use a crystal > with ESR < 40 Ohms? > > > --- In msp430@msp4..., "Kris De Vos" <microbit@c...> wrote: > > Hi Clyde, > > > > A few pointers : > > > > 1. When you use a "high frequency" crystal on LFXTAL1 (XT1) you > have to set the XTS bit in BCSCTL1. > > 2. You have to account for the oscillator fault circuitry. > > If the clock fails, the CPU would enter an irrecoverable > state. Conversely, on startup the MSP430 defaults to the DCO. > > 3. If you switch to XT2 for MCLK, the OFIFG flag is still set > (after power up the crystal oscillators aren't running yet, the DCO > > is however) - So the CPU will straight away switch back to > DCO as its MCLK, because it thimks there's still an OSC fault > > > > You first need to clear OFIFG before switching clock. > > > > The best sequence to switch from DCO to XT2 for MCLK is : > > > > /* either wait enough time for XT2 ( + opt XT1) to settle */ > > // wait XXX mS clocked with the DCO ........... > > > > OR > > > > do (IFG1 &=~OFIFG) > > while (IFG1&OFIFG); /* wait till oscillator(s) have > stabilised...... > > > > AND/OR NOW > > > > IFG1&=~OFIFG; /* case just used delay, clear the > oscillator fault flag */ > > BCSCTL1 &= ~XT2OFF; /* now swicth your clock from DCO -> XT2 > */ > > BCSCTL2 |= SELM_2; > > > > That'll work 100% for you. > > > > PS : > > OFIFG flag clearing means that the XT2 has been running for (I > think) 100 consecutive cycles without fault. > > It does not mean its frequency is accurate. (as a rule of fist, it > takes Q cycles to stabilise) > > As a rough guide, depending on crystal ESR (low profile HC49 has > higher ESR) it takes ~ 5-6 mS to stabilise > > an 6 MHz crystal on XT2. > > It also depends on the phase shift network (loading caps) and the > loading capacitance of your crystal. > > I wouldn't worry too much about the 64 vs. 68 pF caps, you crystal > probably has different characteristics anyway. > > > > > > Kris > > > > > > > > ----- Original Message ----- > > From: Eisenbeis, Clyde [FRCO/MTN] > > To: 'msp430@'msp...' > > Sent: Tuesday, July 02, 2002 7:41 AM > > Subject: RE: [msp430] Re: MCLK output > > > > > > Thanks Peter ... I have it straight now. > > > > In the docs, my sense is that slow freq crystals should use Xin > and high freq crystals should use Xt2in. Yet the fet140_clks.s43 > uses a high freq crystal on Xin. Is there any advantage of using Xin > over Xt2in (assuming I don't need an ACLK)? > > > > I stuck a 1Mhz crystal across Xt2in with a couple of 68pf caps > (did not have any 64pf caps). The crystal appears to be oscillating > ok, but I can't get anything out of MCLK except for the DCO. The > instructions I am using to switch MCLK to Xt2clk are: > > > > BCSCTL1 &= ~XT2OFF; > > BCSCTL2 |= SELM_2; > > > > Any suggestions? > > > > Clyde > > > > > > -----Original Message----- > > From: Forstner, Peter [mailto:msp430@o...] > > Sent: Monday, July 01, 2002 9:31 AM > > To: 'msp430@'msp...' > > Subject: RE: [msp430] Re: MCLK output > > > > > > Clyde, > > An example is at TI's web site http://www.ti.com/sc/msp430 >>> > Code Examples > > > > MSP-FET430P140 Assembler Examples slac014x.zip (38k) > > a.. fet140_clks.s43 - BasicClock Output buffered SMCLK, ACLK > and MCLK > > Regards > > Peter > > > > -----Original Message----- > > From: Eisenbeis, Clyde [FRCO/MTN] [mailto:clyde.eisenbeis@e...] > > Sent: Monday, 01 July, 2002 15:43 > > To: 'msp430@'msp...' > > Subject: RE: [msp430] Re: MCLK output > > > > > > Thanks Chris. Made the change ... still no MCLK. I'm quite > confident the code is downloading and running properly ... I modified > the blinking LED sample code (fet140_1.c) ... the LED blinks, but > still no MCLK. > > -----Original Message----- > > From: dellaenterprises [mailto:dellaenterprises@p...] > > Sent: Friday, June 28, 2002 5:47 PM > > To: msp430@msp4... > > Subject: [msp430] Re: MCLK output > > > > > > --- In msp430@y..., "cteise" <clyde.eisenbeis@e...> wrote: > > > I am unable to see any output from MCLK (pin 48 on an Msp- > > > fet430p140). I tried to set P5 to be an output ... P5 > 0x0F, but > > > still see no MCLK. Any ideas? > > > > You must also set same bit in the P5SEL register to change > the output > > of the pin from a standard I/O to its "alternate function", > i.e. > > output of the MCLK. > > Chris > > > > > > . > > > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > > > > > > > . > > > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > > > > > . > > > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > > > > > > > > > > > > > . > > > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service.
Reply by ●December 4, 20032003-12-04
Hi Braunlen,
Of course I presume the ESR value is a typo.
It should read 40 Ohm, not 40 kOhm :-)
One important note also is that my advice back then was incorrect regarding
the
OFIFG flag.
The sequence was taken from an original app note from TI in Hong Kong.
The proper OFIFG polling is illustrated nowadays :
loop
-----
clear OFIFG
delay a little
test OFIFG, if 1 , go back to <loop>
This has been extensively discussed on this forum some time ago, and is
because the
OFIFG sampling needs some cycles to deassert.
ESR wise :
XT2 oscillator can be tricky to work 100% reliable over full temperature
range and
Vdd range.
Some Pierce oscillators can even suddenly switch to 3OT (third overtone) and
even 5OT
if loading is low enough and Vdd moves around quite a bit.
If this might be a concern with a marginal crystal, put a small series
resistor for XTal,
this will tend to avoid the 3OT mode (and certain Xtal drive issues)
As mentioned back then, always also keep in mind that low-profile HC49S
mostly tend
to have higher ESR than their full profile buddies.
Best is not to skimp and buy a good quality Xtal, not one of those "el
cheapo" crap things.
It also depends on whether the Pierce oscillator is implemented with a FET,
or the classic
CMOS NOT gate. I have asked TI directly about the exact oscillator structure
internally
recently after Andrew Kalman's suggestion that "unbalanced" load
caps will
affect duty cycle
but for some reason I got no reply, whereas I normally get a *prompt* reply.
I must presume that Andrew's suggestion is correct - although of course if
MCLK = XTLCLK/2 or less,
then it doesn't matter, as the dutycycle will be 50%.
These kind of oscillators are well covered in RF design handbooks, and a
search on the Net
probably will return some good info on the subject.
These circuits are not just something one "throws a Xtal and 2 caps
at", it
is afterall literally
the "heart" of your MCU system, and having an osc fault ckt is all
good and
well, but if the
XT2 oscillator fails/changes osc mode, then the whole system fails fatally
anyway !!!!
(This is for production issues mainly of course)
Lastly, Clyde's original question vis-a-vis XT1 vs. XT2 for HF made a lot
of
sense,
as you will for example see that you can't get SMCLK from LFXTAL1 if
it's
xyz MHz
on a F13X.
Hope that helps
-- Kris
www.microbit.com.au
Texas Instruments Inc. endorsed RF/MSP430 consultant
----- Original Message -----
From: "braunlen" <lbraun@lbra...>
To: <msp430@msp4...>
Sent: Friday, December 05, 2003 9:51 AM
Subject: [msp430] Re: MCLK output
> Hi All,
>
> Here is T.I. application engineer response to my question:
>
> Leonard,
>
> The FAQ that you mentioned from the KnowledgeBase is incorrect and is
> being pulled to be corrected. No, the 8MHz crystal can't have any
> ESR. The ESR should be <40k ohms for HF crystals.
>
> Regards,
>
> Tresha Jackson
>
> Analog and Mixed Signal Product Specialist
>
>
>
> --- In msp430@msp4..., "braunlen" <lbraun@n...> wrote:
> > Hello Kris
> >
> > I'll appreciate it very much if you would shed some light on the
> > subject of Crystal's ESR for the MSP430F133.
> >
> > In the T.I. web site KnowledegeBase-Case 32069 it states, "high
> > frequency crystals don't have the ESR < 40 Ohm
limitation".
> >
> > I consider an 8MHz crystal high frequency as far as the MSP430 is
> > concerned.
> > Does this mean that the 8MHz crystal can have any ESR, but the
> > oscillator may start up faster or be more stable if I use a crystal
> > with ESR < 40 Ohms?
> >
> >
> > --- In msp430@msp4..., "Kris De Vos" <microbit@c...>
wrote:
> > > Hi Clyde,
> > >
> > > A few pointers :
> > >
> > > 1. When you use a "high frequency" crystal on
LFXTAL1 (XT1)
> you
> > have to set the XTS bit in BCSCTL1.
> > > 2. You have to account for the oscillator fault circuitry.
> > > If the clock fails, the CPU would enter an irrecoverable
> > state. Conversely, on startup the MSP430 defaults to the DCO.
> > > 3. If you switch to XT2 for MCLK, the OFIFG flag is still set
> > (after power up the crystal oscillators aren't running yet, the
DCO
> > > is however) - So the CPU will straight away switch back to
> > DCO as its MCLK, because it thimks there's still an OSC fault
> > >
> > > You first need to clear OFIFG before switching clock.
> > >
> > > The best sequence to switch from DCO to XT2 for MCLK is :
> > >
> > > /* either wait enough time for XT2 ( + opt XT1) to settle */
> > > // wait XXX mS clocked with the DCO ...........
> > >
> > > OR
> > >
> > > do (IFG1 &=~OFIFG)
> > > while (IFG1&OFIFG); /* wait till oscillator(s) have
> > stabilised......
> > >
> > > AND/OR NOW
> > >
> > > IFG1&=~OFIFG; /* case just used delay, clear
the
> > oscillator fault flag */
> > > BCSCTL1 &= ~XT2OFF; /* now swicth your clock from DCO
->
> XT2
> > */
> > > BCSCTL2 |= SELM_2;
> > >
> > > That'll work 100% for you.
> > >
> > > PS :
> > > OFIFG flag clearing means that the XT2 has been running for (I
> > think) 100 consecutive cycles without fault.
> > > It does not mean its frequency is accurate. (as a rule of fist,
> it
> > takes Q cycles to stabilise)
> > > As a rough guide, depending on crystal ESR (low profile HC49 has
> > higher ESR) it takes ~ 5-6 mS to stabilise
> > > an 6 MHz crystal on XT2.
> > > It also depends on the phase shift network (loading caps) and the
> > loading capacitance of your crystal.
> > > I wouldn't worry too much about the 64 vs. 68 pF caps, you
> crystal
> > probably has different characteristics anyway.
> > >
> > >
> > > Kris
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: Eisenbeis, Clyde [FRCO/MTN]
> > > To: 'msp430@'msp...'
> > > Sent: Tuesday, July 02, 2002 7:41 AM
> > > Subject: RE: [msp430] Re: MCLK output
> > >
> > >
> > > Thanks Peter ... I have it straight now.
> > >
> > > In the docs, my sense is that slow freq crystals should use Xin
> > and high freq crystals should use Xt2in. Yet the fet140_clks.s43
> > uses a high freq crystal on Xin. Is there any advantage of using
> Xin
> > over Xt2in (assuming I don't need an ACLK)?
> > >
> > > I stuck a 1Mhz crystal across Xt2in with a couple of 68pf caps
> > (did not have any 64pf caps). The crystal appears to be
> oscillating
> > ok, but I can't get anything out of MCLK except for the DCO. The
> > instructions I am using to switch MCLK to Xt2clk are:
> > >
> > > BCSCTL1 &= ~XT2OFF;
> > > BCSCTL2 |= SELM_2;
> > >
> > > Any suggestions?
> > >
> > > Clyde
> > >
> > >
> > > -----Original Message-----
> > > From: Forstner, Peter [mailto:msp430@o...]
> > > Sent: Monday, July 01, 2002 9:31 AM
> > > To: 'msp430@'msp...'
> > > Subject: RE: [msp430] Re: MCLK output
> > >
> > >
> > > Clyde,
> > > An example is at TI's web site
http://www.ti.com/sc/msp430
> >>>
> > Code Examples
> > >
> > > MSP-FET430P140 Assembler Examples slac014x.zip (38k)
> > > a.. fet140_clks.s43 - BasicClock Output buffered SMCLK,
> ACLK
> > and MCLK
> > > Regards
> > > Peter
> > >
> > > -----Original Message-----
> > > From: Eisenbeis, Clyde [FRCO/MTN]
> [mailto:clyde.eisenbeis@e...]
> > > Sent: Monday, 01 July, 2002 15:43
> > > To: 'msp430@'msp...'
> > > Subject: RE: [msp430] Re: MCLK output
> > >
> > >
> > > Thanks Chris. Made the change ... still no MCLK. I'm
quite
> > confident the code is downloading and running properly ... I
> modified
> > the blinking LED sample code (fet140_1.c) ... the LED blinks, but
> > still no MCLK.
> > > -----Original Message-----
> > > From: dellaenterprises [mailto:dellaenterprises@p...]
> > > Sent: Friday, June 28, 2002 5:47 PM
> > > To: msp430@msp4...
> > > Subject: [msp430] Re: MCLK output
> > >
> > >
> > > --- In msp430@y..., "cteise"
<clyde.eisenbeis@e...> wrote:
> > > > I am unable to see any output from MCLK (pin 48 on an
Msp-
> > > > fet430p140). I tried to set P5 to be an output ... P5
> > 0x0F, but
> > > > still see no MCLK. Any ideas?
> > >
> > > You must also set same bit in the P5SEL register to change
> > the output
> > > of the pin from a standard I/O to its "alternate
function",
> > i.e.
> > > output of the MCLK.
> > > Chris
> > >
> > >
> > > .
> > >
> > >
> > >
> > >
>
