Hi!
I am using this code to set up the oscillator on a MSP430x14x:

BCSCTL1 |=3D XTS + XT2OFF; // ACLK =3D LFXT1 HF XTAL
BCSCTL3 |=3D LFXT1S1; // 3 =96 16MHz crystal or resonator
// turn external oscillator on
do
{
IFG1 &=3D ~OFIFG; // Clear OSCFault flag
for (ii1 =3D 0xFF; ii1 > 0; ii1--); // Time delay for flag to set
}
while ((IFG1 & OFIFG) =3D=3D OFIFG); // OSCFault flag still set?
BCSCTL2 |=3D SELM1 + SELM0 + SELS; // MCLK =3D SMCLK =3D HF LFXT1 (safe=
)

after having executed the last line I find the OFIFG flg set for ever.
Can anybody explain me the possible reasons?

Thanks,
Giorgio

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Giorgio
The following is a excerpt from code I used a long time in the past.
It is not an exact match but may give you some idea where to look.

-Bill Knight
R O SoftWare

int __low_level_init(void)
{
register int delay;

WDTCTL = WDTPW + WDTHOLD; // stop Watchdog
BCSCTL1 |= XTS + XT2OFF; // LFXT1 = HF XTAL
// ACLK = LFTX1/1
// XT2 Osc is OFF

// other setup code snipped here

// Wait for (LF)XT1 oscillator to come up
// Clear OSC fault flag & set delay count
// Exit loop when no fault for delay count
for (IFG1 &= ~OFIFG, delay = 255; delay; )
{
if (IFG1 & OFIFG) // check OSC fault flag
{
// it's set
IFG1 &= ~OFIFG; // clear OSC fault flag
delay = 255; // reset delay count
}
else
--delay; // clear, decrement delay
}

BCSCTL2 |= SELM_3 + // MCLK = LFXT1/1
DIVM_0;

IE1 = ACCVIE | NMIIE | OFIE; // enable CPU fault interrupts

_BIS_SR(SCG1 + SCG0); // turn off DCO & SMCLK
return 0; // 0 => no C init
}

giorgioel wrote:
> Hi!
> I am using this code to set up the oscillator on a MSP430x14x:
>
> BCSCTL1 |= XTS + XT2OFF; // ACLK = LFXT1 HF XTAL
> BCSCTL3 |= LFXT1S1; // 3 – 16MHz crystal or resonator
> // turn external oscillator on
> do
> {
> IFG1 &= ~OFIFG; // Clear OSCFault flag
> for (ii1 = 0xFF; ii1 > 0; ii1--); // Time delay for flag to set
> }
> while ((IFG1 & OFIFG) == OFIFG); // OSCFault flag still set?
> BCSCTL2 |= SELM1 + SELM0 + SELS; // MCLK = SMCLK = HF LFXT1 (safe)
>
> after having executed the last line I find the OFIFG flg set for ever.
> Can anybody explain me the possible reasons?
>
> Thanks,
> Giorgio
------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Giorgio,
there are some things wrong with your description:

> BCSCTL3 |= LFXT1S1; // 3 � 16MHz crystal or
> resonator
MSP430x14x only works up to 8MHz, not 16MHz (according to the datasheet) and there is no BCSCTL3 register.
It seams you're using an MSP430F2xx OSC init code with an MSP430F14x part. I guess you're using IARs default #include "io430.h" instead of #include , otherwise your code shouldn't compile. OR you're quoting the wrong MSP model.

> while ((IFG1 & OFIFG) == OFIFG); // OSCFault flag still set?
> BCSCTL2 |= SELM1 + SELM0 + SELS; // MCLK = SMCLK = HF LFXT1 >(safe)
>
> after having executed the last line I find the OFIFG flg set for
> ever.
>
You can only reach the last line (BCSCTL2...) if the oscilator starts.

Regardless, you need to read the entire chapter of the Clock Module of the User Guide of the MSP family you're using and understand what the code does.

But if it's a homemade PCB, you might have a hardware problem with soldering the XTAL or the CAPs.

Michael K.

--- In m...@yahoogroups.com, "giorgioel" wrote:
>
> Hi!
> I am using this code to set up the oscillator on a MSP430x14x:
>
> BCSCTL1 |= XTS + XT2OFF; // ACLK = LFXT1 HF XTAL
> BCSCTL3 |= LFXT1S1; // 3 � 16MHz crystal or resonator
> // turn external oscillator on
> do
> {
> IFG1 &= ~OFIFG; // Clear OSCFault flag
> for (ii1 = 0xFF; ii1 > 0; ii1--); // Time delay for flag to set
> }
> while ((IFG1 & OFIFG) == OFIFG); // OSCFault flag still set?
> BCSCTL2 |= SELM1 + SELM0 + SELS; // MCLK = SMCLK = HF LFXT1 (safe)
>
> after having executed the last line I find the OFIFG flg set for ever.
> Can anybody explain me the possible reasons?
>
> Thanks,
> Giorgio
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m...@yahoogroups.com, "Michael" wrote:
> ...
> It seams you're using an MSP430F2xx OSC init code with an MSP430F14x part. I guess you're using IARs default #include "io430.h" instead of #include , otherwise your code shouldn't compile. OR you're quoting the wrong MSP model.
> ...

In an IAR project, you need to (a) specify the [Target] chip you are using in the [General Options], (b) use only the peripherals this chip has in your source code, and (c) include the appropriate header file(s).

Like what Michel said, the default for (c) is #include
and the code (b) posted by Giorgio was obviously for MSP430F2xx chips while he intended to use MSP430F14x.

Let us see what happens under the following different scenarios:

Scenario #1. He incorrectly set up IAR for [Target] = MSP430F2001 and let the #include file to be . I think the consequence is, the compiler will not generate errors or warnings. But IAR will send waring msg when he tries to download or debug because the actual [Target] is not a MSP430F2001.

Scenario #2. He correctly set up IAR for [Target] = MSP430F148 and let the #include file to be . I think the consequence is, the compile will generate errors because will automatically include based on the fact that the [Target] is MSP430F148.

Scenario #3. He correctly set up IAR for [Target] = MSP430F148 and changed the #include file to or . I think the consequence is the same as Scenario #2. (Compiler error.)

Scenario #4. He correctly set up IAR for [Target] = MSP430F148 and changed the #include file to or . I think the consequence is really bad. The compiler will not generate any errors or warnings. And when he tries to download or debug, there will be no warning either. (But the MSP430F148 will not run the code for MSP430F2xx correctly. And he might wasting long hours trying to figure out why.)

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Sorry guys!
While pasting the source code I wrongly changed BCSCTL2 in BCSCTL3.
In any case even if I am using the right register BCSCTL2 the OSCFault flag is immediately set and what is absolutely strange is that the microprocessor works well anyway (I mean it seems to have the selected clock working well)....

Giorgio
--- In m...@yahoogroups.com, "old_cow_yellow" wrote:
>
> --- In m...@yahoogroups.com, "Michael" wrote:
> > ...
> > It seams you're using an MSP430F2xx OSC init code with an MSP430F14x part. I guess you're using IARs default #include "io430.h" instead of #include , otherwise your code shouldn't compile. OR you're quoting the wrong MSP model.
> > ...
>
> In an IAR project, you need to (a) specify the [Target] chip you are using in the [General Options], (b) use only the peripherals this chip has in your source code, and (c) include the appropriate header file(s).
>
> Like what Michel said, the default for (c) is #include
> and the code (b) posted by Giorgio was obviously for MSP430F2xx chips while he intended to use MSP430F14x.
>
> Let us see what happens under the following different scenarios:
>
> Scenario #1. He incorrectly set up IAR for [Target] = MSP430F2001 and let the #include file to be . I think the consequence is, the compiler will not generate errors or warnings. But IAR will send waring msg when he tries to download or debug because the actual [Target] is not a MSP430F2001.
>
> Scenario #2. He correctly set up IAR for [Target] = MSP430F148 and let the #include file to be . I think the consequence is, the compile will generate errors because will automatically include based on the fact that the [Target] is MSP430F148.
>
> Scenario #3. He correctly set up IAR for [Target] = MSP430F148 and changed the #include file to or . I think the consequence is the same as Scenario #2. (Compiler error.)
>
> Scenario #4. He correctly set up IAR for [Target] = MSP430F148 and changed the #include file to or . I think the consequence is really bad. The compiler will not generate any errors or warnings. And when he tries to download or debug, there will be no warning either. (But the MSP430F148 will not run the code for MSP430F2xx correctly. And he might wasting long hours trying to figure out why.)
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

If the OSCFault bit is set, then you are not testing for it properly as it should never exit the test loop...

this should be in the init file:

__bis_SR_register(OSCOFF); //turn off the LF oscillator so the OFIFG does not fault

do
{
IFG1 &= ~OFIFG; // Clear OSCFault flag
for (i = 0x47FF; i > 0; i--); // Time for flag to set
}
while ((IFG1 & OFIFG)); // OSCFault flag still set?

-Bill

--- In m...@yahoogroups.com, "giorgioel" wrote:
> Sorry guys!
> While pasting the source code I wrongly changed BCSCTL2 in BCSCTL3.
> In any case even if I am using the right register BCSCTL2 the OSCFault flag is immediately set and what is absolutely strange is that the microprocessor works well anyway (I mean it seems to have the selected clock working well)....
>
> Giorgio
> --- In m...@yahoogroups.com, "old_cow_yellow" wrote:
> >
> > --- In m...@yahoogroups.com, "Michael" wrote:
> > > ...
> > > It seams you're using an MSP430F2xx OSC init code with an MSP430F14x part. I guess you're using IARs default #include "io430.h" instead of #include , otherwise your code shouldn't compile. OR you're quoting the wrong MSP model.
> > > ...
> >
> > In an IAR project, you need to (a) specify the [Target] chip you are using in the [General Options], (b) use only the peripherals this chip has in your source code, and (c) include the appropriate header file(s).
> >
> > Like what Michel said, the default for (c) is #include
> > and the code (b) posted by Giorgio was obviously for MSP430F2xx chips while he intended to use MSP430F14x.
> >
> > Let us see what happens under the following different scenarios:
> >
> > Scenario #1. He incorrectly set up IAR for [Target] = MSP430F2001 and let the #include file to be . I think the consequence is, the compiler will not generate errors or warnings. But IAR will send waring msg when he tries to download or debug because the actual [Target] is not a MSP430F2001.
> >
> > Scenario #2. He correctly set up IAR for [Target] = MSP430F148 and let the #include file to be . I think the consequence is, the compile will generate errors because will automatically include based on the fact that the [Target] is MSP430F148.
> >
> > Scenario #3. He correctly set up IAR for [Target] = MSP430F148 and changed the #include file to or . I think the consequence is the same as Scenario #2. (Compiler error.)
> >
> > Scenario #4. He correctly set up IAR for [Target] = MSP430F148 and changed the #include file to or . I think the consequence is really bad. The compiler will not generate any errors or warnings. And when he tries to download or debug, there will be no warning either. (But the MSP430F148 will not run the code for MSP430F2xx correctly. And he might wasting long hours trying to figure out why.)
>

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )