I may have missed the gist of this thread, but think a typical MSP430
useage would be a variant of case 2 where you run ACLK on the crystal and, when
awake, MCLK from the DCO.
Bruce
-----Original Message----- From: Eisenbeis, Clyde [FRCO/MTN]
[mailto:clyde.eisenbeis@emersonprocess.com] Sent: Wednesday, July 03,
2002 5:22 AM To: 'msp430@yahoogroups.com' Subject:
RE: [msp430] Re: MCLK output
Hi Kris,
Thanks for the clear, concise description.
If ACLK is not needed, is there any advantage /
disadvantage with using Xin instead of Xt2in for a high freq
clock?
For my future reference, and perhaps for others, I
would like to create descriptions / snippets of sample code for each of the
crystal combinations. Please make additions / corrections to the
following.
----
Crystal freq ranges:
low
freq crystal: 32.768 Khz ... min / max ???
high
freq crystal: 1 Mhz - 8 Mhz
Setup:
WDTCTL = WDTPW + WDTHOLD; // Stop
watchdog timer //Next two instructions give ability to watch the clocks on a
scope P5DIR =
0xFF;
//Set P5 to output
direction P5SEL =
0xFF;
//Set P5 to output MCLK, ACLK, etc.
Case
1: No crystals ... use DCO
Advantage:
no external parts
Disadvantage: freq may not be stable
Default
condition after power up ... around 750 Khz
Case
2: One low freq crystal on Xin
Advantage:
lowest power consumption
Disadvantage:
???
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 &=
~XTS; //Set Xin
to low freq BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
Case
3: One high freq crystal on Xin
Advantage:
???
Disadvantage:
???
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 |=
XTS; //Set Xin
to high freq BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
Case 4: One high freq crystal on
Xt2in
Advantage: ???
Disadvantage: No Aux
Clock
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 &=
~XT2OFF; //Set Xt2in
on BCSCTL2 |=
SELM_2; //Set
MCLK to use Xt2in
Case 5: One low freq crystal on Xin and one
high freq crystal on Xt2in
Advantage:
???
Disadvantage:
???
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 &=
~XTS; //Set Xin
to low freq BCSCTL1 &=
~XT2OFF; //Set Xt2in
on BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
...
BCSCTL2 |=
SELM_2; //Set
MCLK to use Xt2in
...
BCSCTL2 |= SELM_3; //Set
MCLK to use Xin
----
-----Original Message----- From: Kris De Vos
[mailto:microbit@cyberspace.net.au] Sent: Monday, July 01, 2002 8:41
PM To: msp430@yahoogroups.com Subject: Re: [msp430] Re: MCLK
output
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@yahoogroups.com'
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@onlinehome.de] Sent: Monday, July 01, 2002 9:31
AM To: 'msp430@yahoogroups.com' Subject: RE:
[msp430] Re: MCLK output
Clyde,
An example
is at TI's web site http://www.ti.com/sc/msp430
>>> Code Examples
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@prodigy.net] Sent: Friday, June 28, 2002 5:47
PM To: msp430@yahoogroups.com 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
If ACLK is not needed, is there any advantage /
disadvantage with using Xin instead of Xt2in for a high freq
clock?
Not that I can see, but .......
As in all cases, it heavily depends on your
apllication, priority of design criteria etc.
XT1 and XT2 I think are there mainly for 2 reasons
:
1. Maintain a good upwards
compatibility with F1121 - style applications.
2. Have a low power "system clock"
or even RTC. (~ 1 - 1.5 uA -> LPM3)
When I for example do network applications, ACLK
typically is used to generate a "system clock",
much like the Bluetooth protocol stack relies
on.
It allows the upper layers to accurately "predict"
when an RF node (if that's the case) should wake up
with a small "uncertainty" window, to intercept a
transmission, thereby using minimal power.
Nodes then synchronise their ACLKs to other nodes
etc. through the Data Link Layer.
You can do really nice things like wake up XT2
and let's say during the eg. 5 mS needed to stabilise
XT2,
you can clock on the DCO and concurrently do CPU
crunching like CRC calculations, or other SW intensive
stuff
with the DCO at highest speed.
That's one of the many beauties of
MSP430.........
etc etc .......
The only one to be careful with is when you freely
change the clocking when your "high frequency" is needed for
SMCLK.
Always keep in mind that on F13X - F14X etc. LFXTAL1
cannot supply SMCLK internally
(say you are clocking USARTs with SMCLK at a few MHz,
and that clock is LFXTAL1, the only way to do that is
to "output" ACLK and DC couple it (hardwired) back
into XT2IN. (they're only 3 or 4 pins or so apart), leave XT2OUT
open.
I've had clients who ported F1121 designs to
F14X and got stung with that.
Case
2: One low freq crystal on Xin
Advantage:
lowest power consumption
Disadvantage:
???
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 &=
~XTS; //Set Xin
to low freq BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
Disadvantage :
1. If you need LPM4, and at
startup, depending on your "watch crystal"
ACLK startup
can easily takes hundreds of mS, even up to 1 Second....
2. If you need an "accurate" DCO
MCLK / SMCLK of several MHz, it takes time
to "lock" the DCO
to ACLK (again depending on accuracy requirement)
Parts with the
FLL will do better, but there os other issues there too.
It entirely depends on whether your app benefits from
it, or can afford to do it that way.
An extra HC49S crystal for XT2 at a suitable
frequency doesn't cost the world .........
Case
3: One high freq crystal on Xin
Advantage:
???
Disadvantage:
???
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 |=
XTS; //Set Xin
to high freq BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
Here you should set XTS before you start testing for a "stable"
Xin ie :
BCSCTL1 |=
XTS; //Set Xin
to high freq
........
do
(IFG1 &= ~OFIFG)
while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault flag
---> At this moment I would
also insert a delay as appropriate to fully
stabilise
LXFTAL1 and / or XT2 .............
(again, it
d_e_p_e_n_d_s )
BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
No specific advantage/disadvantage either way I
think, depends on.
If you have a small app, this kind of stuff could run
in smaller parts......
Case 4: One high freq crystal on
Xt2in
Advantage: ???
Disadvantage: No Aux
Clock
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 &=
~XT2OFF; //Set Xt2in
on BCSCTL2 |=
SELM_2; //Set
MCLK to use Xt2in
Again, depends on app. Might be
many applications where you just don't need
ACLK.
But you can still divide down
and derive your ACLK from XT2 + the peripherals
have a very extensive choice of
sources of clock (ie. clock(s) / divided down /
external/internal events such
as capture compare etc.
Case 5: One low freq crystal on Xin and one
high freq crystal on Xt2in
Advantage:
???
Disadvantage:
???
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 &=
~XTS; //Set Xin
to low freq BCSCTL1 &=
~XT2OFF; //Set Xt2in
on BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
Same thing again, configure your
modes of operation before polling/delays
start on the crystal
oscillator.
ie the first line should be
:
BCSCTL1 &=
~XTS; //Set Xin
to low freq (Defaults that way anyway, ie. ACLK will start up on
POR)
............
After that of course you are free
to change clocks to the CPU "on the fly"
With multi clocks, make sure
you have some sort of an "exception handler"
(preferably INT driven) that
detects an oscillator fault, vectors - rectifies
the clock problem and then
resumes normal app execution.
Otherwise you might end up with a
UART being suddenly clocked at say 750 kHz
instead of say 7.7328 MHz or
whatever after an ESD zap etc etc.
Have fun !!!!!!!!!!!
Kris
Reply by Kevin Brewster●July 4, 20022002-07-04
I don't this code will work. The osc fault
detector is designed to work with high-speed xtals only; a 32K xtal appears to
be fault and OFIFG continually sets. I tried code similar to
what you wrote and found that often it wouldn't powerup properly -- it was
stuck in the OFIFG testing loop. Sometimes it did start up, but I think
that's because I wasn't waiting long enough between clearing and
testing the flag - it takes a little while to set
itself.
It's a bit of a pain actually - there is
no failsafe DCO takeover when running MCLK from a 32K xtal. If
it fails, things stop.
Does anyone have any ideas / solutions to
this?
Case
2: One low freq crystal on Xin
Advantage:
lowest power consumption
Disadvantage:
???
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 &=
~XTS; //Set Xin
to low freq BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
Reply by Kris De Vos●July 4, 20022002-07-04
Huh ?
That's one of the first things you'd expect from MSP430, running
ACLK/MCLK @ 32.768 and
choose to use the DCO if necessary.
The Osc fault ckt. asserts OFIFG after ~ 100 consecutive samples driven
by an RC ~ 1 MHz clock
are missed.
At a sample interval of ~ 1 uS, 100 sampes constitutes ~ 3 ACLK
"ticks".
If the claim below were to be true, then conversely an INT out if LPM3/4
would not work, because
there the DCO services the INT. max 6 uS start up, and 6 cycles in/ 5
cycles out for INT).
Let me assure you, all those things work flawless......
I think you overlooked something when you tried this
oiut..............
You are right that there could be a "Nyquist" effect in rate of
clearing/testing the flag, but when so,
a delay would make it worse, because if the hypothesis were true, then
a previously "stable"
oscillator could have had a new assertion of OFIFG within ~ 100 uS.
Lastly, it's not possible anyway, becuase the clear/test loop would
have to manage to do this within
3 CPU cycles.
It can't even set or clear a bit in that time, it needs 4 clocks for
that alone..............
You might have come across something weird that I'm not aware of, and
if so, I'd love to know
about it, but as I mentioned before - Account for startups of 100s of mS
with "watch crystals".
Their Q is still very high, and I've seen oscillatords like that take
up to 1 second to properly start.
The main factor is the Motional Resistance of the crystal.
Make sure you get decent quality crystals, and not shitty
ones.........
I'd like to know more about this issue though ......
Kris
----- Original Message -----
From: Kevin Brewster
To: msp430@yahoogroups.com
Sent: Thursday, July 04, 2002 5:08
PM
Subject: Re: [msp430] Re: MCLK
output
I don't this code will work. The osc fault
detector is designed to work with high-speed xtals only; a 32K xtal appears to
be fault and OFIFG continually sets. I tried code similar to
what you wrote and found that often it wouldn't powerup properly -- it was
stuck in the OFIFG testing loop. Sometimes it did start up, but I think
that's because I wasn't waiting long enough between clearing and
testing the flag - it takes a little while to set
itself.
It's a bit of a pain actually - there is
no failsafe DCO takeover when running MCLK from a 32K xtal. If
it fails, things stop.
Does anyone have any ideas / solutions to
this?
Case
2: One low freq crystal on Xin
Advantage:
lowest power consumption
Disadvantage:
???
do
(IFG1 &= ~OFIFG) while
(IFG1 & OFIFG); //Wait until
oscillator has
stabilized IFG1 &=
~OFIFG; //Clear
the oscillator fault
flag BCSCTL1 &=
~XTS; //Set Xin
to low freq BCSCTL2 |=
SELM_3; //Set
MCLK to use Xin
">Yahoo!
Terms of Service.
Reply by Kris De Vos●July 4, 20022002-07-04
Maybe one other issue :
Do bear in ind that most F1XXX parts so far do NOT have a proper BOD
on-board.
TI say "it does", but do not rely on it, because it's not there in a
F13X/14X etc.
A power up timer is a poor trade off for a proper BOD.
It also would depend on how your Vcc ramps up at start up.
If you have it connected onto a standard lab P/S - "rattle" your Vcc
connection to your
circuit on/off a bit when connecting to the P/S, it'll go la-la land
pretty quick.
But even then, it will always recover eventually if you implement proper
exception handling.
(At least, that's what I've seen so far with FET kits...)
People repeatedly overlook the importance of proper Brown-out detect ckts -
even with a battery
supply !
Could there have been a problem there ?
Reply by Kevin Brewster●July 4, 20022002-07-04
Hi Kris, thanks for your
ideas.
Believe me I was surprised
also. I just love these things at 32kHz - solved a heap of my
EMI problems "just like that"! :-)
I might go back and play with
it some more when I have time, but for now I just run off the DCO for about a
second (software loop) before switching over the LFXT source. This method
is working fine, tested from -20 to +90. My concern about the the lack
of DCO backup in the event of a crystal failure came from (apart from physical
evidence) the following section of the user guide:
3.3.2.1 Oscillator Fault Control in the Basic Clock
System The oscillator-fault signal is triggered when the LFXT1
oscillator is configured to run in HF mode but is not running, stops
running after being operational, or is switched off. The oscillator-fault
signal is also triggered under the same conditions for the XT2 oscillator,
present in some devices. Note that a PUC signal can trigger an
oscillator fault, because the PUC switches the LFXT1 to LF mode, therefore
switching off the HF mode. The PUC signal also switches off the XT2
oscillator.
Which suggests that the OFIFG
is going to stay set whenever a 32K xtal is connected to LFXT1.
Re your second email, thanks
for the tip but I'm almost certain it isn't a brownout problem.
I have a 3.0 volt external reset controller looking after that side of things -
automotive supply voltages go all over the place (learned the hard
way)!
Reply by Kris De Vos●July 4, 20022002-07-04
That reminds me I still have to run the JTAG/blowing anti-fuse issue past
TI, as discussed with CP8071.
I will contact TI in Freising, the couple of guys there designed the
MSP430, they should know the
full story.
I'm not sure whether the ".....when configured in HF mode..." does
explicitly imply that it isn't
when LFXTAL1 is indeed in non-HS mode.
I'll post what TI said "from the horses' mouth"
Kris
----- Original Message -----
From: Kevin Brewster
To: msp430@yahoogroups.com
Sent: Thursday, July 04, 2002 9:33
PM
Subject: Re: [msp430] Re: MCLK
output
Hi Kris, thanks for your
ideas.
Believe me I was surprised
also. I just love these things at 32kHz - solved a heap of my
EMI problems "just like that"! :-)
I might go back and play with
it some more when I have time, but for now I just run off the DCO for about a
second (software loop) before switching over the LFXT source. This method
is working fine, tested from -20 to +90. My concern about the the lack
of DCO backup in the event of a crystal failure came from (apart from physical
evidence) the following section of the user guide:
3.3.2.1 Oscillator Fault Control in the Basic Clock
System The oscillator-fault signal is triggered when the LFXT1
oscillator is configured to run in HF mode but is not running, stops
running after being operational, or is switched off. The oscillator-fault
signal is also triggered under the same conditions for the XT2 oscillator,
present in some devices. Note that a PUC signal can trigger an
oscillator fault, because the PUC switches the LFXT1 to LF mode, therefore
switching off the HF mode. The PUC signal also switches off the XT2
oscillator.
Which suggests that the OFIFG
is going to stay set whenever a 32K xtal is connected to LFXT1.
Re your second email, thanks
for the tip but I'm almost certain it isn't a brownout problem.
I have a 3.0 volt external reset controller looking after that side of things -
automotive supply voltages go all over the place (learned the hard
way)!
">Yahoo! Terms
of Service.
Reply by Kevin Brewster●July 4, 20022002-07-04
Thanks; I look forward to
their response.
Kevin.
I'll post what TI said "from the horses' mouth"
Kris
Reply by Kris De Vos●July 4, 20022002-07-04
Well, to my greatest surprise, you are right Kevin.
I think we should all note the follwing below :
Hi Kris,
it depends on the device that is
used. With the "new" F4xx series and the low-power oscillator the fault
detection should work with the LF osc. and 32kHz. For all other devices there
is no fault detection for the LF oscillator (only for the HF osc.).
Regards,
Volker
This a word-for-word pasted reply of one of the guys that developed MSP430
for TI/ Freising
There you go.
Kris
----- Original Message -----
From: Kevin Brewster
To: msp430@yahoogroups.com
Sent: Thursday, July 04, 2002 10:44
PM
Subject: Re: [msp430] Re: MCLK
output
Thanks; I look forward to
their response.
Kevin.
I'll post what TI said "from the horses' mouth"
Kris
">msp430-unsubscribe@egroups.com
">Yahoo!
Terms of Service.
Reply by Eisenbeis, Clyde [FRCO/MTN]●July 8, 20022002-07-08
Descriptions / snippets of sample code for each of the crystal
combinations.
Please make additions / corrections.
Draft #2 ... 8 Jul 02
----
Crystal freq ranges:
Low freq crystal: 32.768 Khz ... min / max ???
High freq crystal: 1 Mhz - 8 Mhz.
Nice feature:
Use the low freq crystal during sleep time to minimize power consumption.
When awake, use the DCO (or high freq crystal) to perform fast
computations
then go back to sleep.
For power consumption reasons, it is important to turn off the high freq
crystal when sleeping. Note that the osc needs time to get up and
running
each time it is re-started.
Setup prior to selecting crystals:
WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer
//Next two instructions give ability to watch the clocks on a scope
P5DIR = 0xFF; //Set P5 to output direction
P5SEL = 0xFF; //Set P5 to output MCLK, ACLK, etc.
Case 1: No crystals ... use DCO
Advantage: No external parts.
Lower power consumption than high freq crystal.
Disadvantage: Freq may vary.
Higher power consumption than low freq crystal.
Default condition after power up ... around 750 Khz
Case 2: One low freq crystal on Xin
Advantage: Lowest power consumption.
Disadvantages: The startup of ACLK is very slow ... up to 1 second.
Can be slow to "lock" the DCO to ACLK.
BCSCTL1 &= ~XTS; //Set Xin to low freq
do
{
IFG1 &= ~OFIFG; //Clear OSCFault flag
for (i = 0xFF; i > 0; i--); //Time for flag to set
}
while (IFG1 & OFIFG); //OSCFault flag still set?
IFG1 &= ~OFIFG; //Clear osc. fault int. flag
BCSCTL2 |= SELM_3; //Set MCLK to use Xin
Note: The above listing may work only with the new F4xx series.
There is no fault detection for the low freq osc. The
solution for this is ???????????????
Case 3: One high freq crystal on Xin
Advantage: Faster computations ... same as Case 4
Disadvantage: Higher power consumption ... increases with freq.
BCSCTL1 |= XTS; //Set Xin to high freq
do
{
IFG1 &= ~OFIFG; //Clear OSCFault flag
for (i = 0xFF; i > 0; i--); //Time for flag to set
}
while (IFG1 & OFIFG); //OSCFault flag still set?
IFG1 &= ~OFIFG; //Clear osc. fault int. flag
BCSCTL2 |= SELM_3; //Set MCLK to use Xin
Case 4: One high freq crystal on Xt2in
Advantage: Faster computations ... same as Case 3
Disadvantage: Higher power consumption ... increases with freq.
No Aux Clock
BCSCTL1 &= ~XT2OFF; //Set Xt2in on
do
{
IFG1 &= ~OFIFG; //Clear OSCFault flag
for (i = 0xFF; i > 0; i--); //Time for flag to set
}
while (IFG1 & OFIFG); //OSCFault flag still set?
IFG1 &= ~OFIFG; //Clear osc. fault int. flag
BCSCTL2 |= SELM_2; //Set MCLK to use XT2
Case 5: One low freq crystal on Xin and one high freq crystal on Xt2in
Advantage: Can run very low power when sleeping and very fast computations
when awake.
Disadvantage: Need two crystals.
BCSCTL1 &= ~XTS; //Set Xin to low freq
BCSCTL1 &= ~XT2OFF; //Set Xt2in on
do
{
IFG1 &= ~OFIFG; //Clear OSCFault flag
for (i = 0xFF; i > 0; i--); //Time for flag to set
}
while (IFG1 & OFIFG); //OSCFault flag still set?
IFG1 &= ~OFIFG; //Clear osc. fault int. flag
BCSCTL2 |= SELM_3; //Set MCLK to use Xin
...
BCSCTL2 |= SELM_2; //Set MCLK to use Xt2in
...
BCSCTL2 |= SELM_3; //Set MCLK to use Xin
----
Question 1: What are the max / min values for a low freq crystal?
Question 2: Regarding Kris De Vos' comment,
BCSCTL1 |= XTS; //Set Xin to high freq
......
do (IFG1 &= ~OFIFG)
while (IFG1 & OFIFG); //Wait until oscillator has stabilized
IFG1 &= ~OFIFG; //Clear the oscillator fault flag
---> At this moment I would also insert a delay as appropriate to fully
stabilise LXFTAL1 and / or XT2 ............. (again, it d_e_p_e_n_d_s )
BCSCTL2 |= SELM_3; //Set MCLK to use Xin
It is not clear why the delay is needed. At startup, we are running off of
the DCO which will quite likely vary in freq. Or is the concern that the
crystal is not up and running fully yet?
Question 3: Regarding Kris De Vos' comment, "You can do really nice
things
like wake up XT2 and let's say during the eg. 5 mS needed to stabilise XT2,
you can clock on the DCO and concurrently do CPU crunching like CRC
calculations, or other SW intensive stuff with the DCO at highest speed.
That's one of the many beauties of MSP430........." If I understand
this
correctly, it is possible to instantaneously switch to the DCO without any
delay (as is necessary with the crystals)?
Question 4: Regarding TI's comment, " With the "new" F4xx
series and the
low-power oscillator the fault detection should work with the LF osc. and
32kHz. For all other devices there is no fault detection for the LF
oscillator (only for the HF osc.). " What is the proposed solution?
Clyde Eisenbeis
