MCLK is not 32 times ACLK

What are you xcap settings? It looks like your crystal is stable since you are reading the correct ACLK. To verify the setup can you take a UCS example from the following link, run it as-is, and see the same behavior? http://www.ti.com/lit/zip/slac166

I do not think the examples from that link can help.

gcgplge:

(a) Are you routing ACLK to P1.1, P2,6, or P11.0 to measure its frequency? If you probe XTIN or XTOUT directly, you might disterb the oscillator.

(b) Is the CPU running when you measure MCLK frequency? (MCLK can be routed to P2.0 or P11.1.  SMCLK can be routed to P1.6, P4.7, or P11.2.)

(c) Is the JTAG still attached when you measure MCLK frequency?

(d) If so, you can occasionally stop the CPU and examine the UCS registers. The UCSCTL0:MODx bits may occasionally change by 1 count. The UCSCTL0:DCOx bits should not change at all. You may also want to examine and clear various flag bits in UCSCTL7 and UCSCTL6. S

(e) You may also try to use REFO (instead of external crystal) to source ACLK and check if MCLK is 32 times of ACLK. The REFO is not as accurate as the external crystal, but you will be able to see if MCLK is 32 times or not.

(f) The FLL+ has its limitations. I do not know how accurate it can get. But the DCO taps are something like 2% to 12% appart. Thus after the FLL+ automatically adjust MOD, the average frequency over 32 cycles should be something like 0.06% to 0.38%. What you observed is about 0.1%. It could be the limitation of the FLL+.

I am using the development board MSP-TS430PZ5x100.  I soldered the watch crystal from the kit and measured a stable 32.76690 Hz.

I set up to monitor the following clocks:

ACLK = XT1CLK at P11.0

MCLK =DCOCLK at P11.1

SCLK = DCOCLKDIV at P11.2.

With UCSCTL2 = FLLD_1 + 31, I measure MCLK = 2.118xxx Mhz and not stable and NOT 64*XT1CLK.  But with UCSCTL2 = FLLD_0 + 63, I measure MCLK = 2.09780 Mhz which is 64*XT1CLK.  It seems that the FLL is not stable when the prescaler is in use.

Has anyone tried this?

Hi Brandon,

                      I hav a question about the crystal oscillator : is there any kind of clock source built in MSP430F2274 that gives 32khz or default DCO which is approximately  1.2 Mhz  withot connecting an external crystal oscillator bcoz in user guide SLAS504B  they have given that 32khz crystal oscillator and DCO can be adjusted with factory settings.

 I am sure that without connecting the external crystal oscillator or any kind of clock source there cant be any clock genrations  please help me understand this topic clearly

because I am not sure of  how the DCO is sourced from and does it multiply ( I'm sure it wont multiply but I need clarity ) the clock n generate more frequency than the source clock.??

SRIHK said:

Hi Brandon,

                      I hav a question about the crystal oscillator : is there any kind of clock source built in MSP430F2274 that gives 32khz or default DCO which is approximately  1.2 Mhz  withot connecting an external crystal oscillator bcoz in user guide SLAS504B  they have given that 32khz crystal oscillator and DCO can be adjusted with factory settings.

 I am sure that without connecting the external crystal oscillator or any kind of clock source there cant be any clock genrations  please help me understand this topic clearly

because I am not sure of  how the DCO is sourced from and does it multiply ( I'm sure it wont multiply but I need clarity ) the clock n generate more frequency than the source clock.??

Yes. The 2xx and 4xx series have completely different clock systems. Because the 2xx series does not have the FLL system an external crystal is not needed to configure the DCO and the default value is about 1.2MHz. It is completely independent from the xtal. There is also calibration constants that can be loaded into the DCO registers of the 2xx such that specific frequency settings can be acheived (again, with no xtal needed).

gcgplge said:

I am using the development board MSP-TS430PZ5x100.  I soldered the watch crystal from the kit and measured a stable 32.76690 Hz.

I set up to monitor the following clocks:

ACLK = XT1CLK at P11.0

MCLK =DCOCLK at P11.1

SCLK = DCOCLKDIV at P11.2.

With UCSCTL2 = FLLD_1 + 31, I measure MCLK = 2.118xxx Mhz and not stable and NOT 64*XT1CLK.  But with UCSCTL2 = FLLD_0 + 63, I measure MCLK = 2.09780 Mhz which is 64*XT1CLK.  It seems that the FLL is not stable when the prescaler is in use.

Has anyone tried this?

This happens when using a TI example from my earlier post? Which code file did you use?

ok Thank u Brandon for the reply and one more questions is that so without connecting XTAL to MSP430F2274 I can get frequencies upto 16Mhz  with the default DCO which is 1.2 Mhz and so that I dont need any external crytall at all.

and also do u have any links or support documents or example codes that support  MSP430F2274 I2C interface with RTC (real time clock)  ? 

Hi SRIHK,

have you had a look at the C Samples Codes provided by TI? Pls refer to http://www.ti.com/lit/zip/slac123 for the MSP40F2274 related samples. Ther're a lot of different samples with I2C communication.

One point is not clear to me; do you want to implemet your own real time clock in the F2274 or do you want to use an external device (maybe a MCU supervisor chip) and talk to it via I2C? MSP-EXP430F5438 Example Software and USB Drivers (Rev. D) (slac227d.zip, http://www.ti.com/litv/zip/slac227d ) presents an RTC implemetation for the F5438 which you could easily adopt to the F2274.

Rgds
G**buster

SRIHK said:

so without connecting XTAL to MSP430F2274 I can get frequencies upto 16Mhz  with the default DCO which is 1.2 Mhz and so that I dont need any external crytall at all.

Correct. The calibration constants I mentioned above have a 16MHz setting:

  BCSCTL1 = CALBC1_16MHZ;                   // Set range
  DCOCTL = CALDCO_16MHZ;                    // Set DCO step + modulation*/

G**kbuster said:

Hi SRIHK,

have you had a look at the C Samples Codes provided by TI? Pls refer to http://www.ti.com/lit/zip/slac123 for the MSP40F2274 related samples. Ther're a lot of different samples with I2C communication.

One point is not clear to me; do you want to implemet your own real time clock in the F2274 or do you want to use an external device (maybe a MCU supervisor chip) and talk to it via I2C? MSP-EXP430F5438 Example Software and USB Drivers (Rev. D) (slac227d.zip, http://www.ti.com/litv/zip/slac227d ) presents an RTC implemetation for the F5438 which you could easily adopt to the F2274.

Rgds
G**buster

I wanted to add to this answer: we also have the RTC library: http://focus.ti.com/general/docs/techdocsabstract.tsp?abstractName=slaa290

Brandon,

When I used msp430x54x_UCS_4, I measured 2.457445Mhz at MCLK which translate to 4.914890 Mhz DCOCLK.  This is as expected but sometimes I see the frequency jump to 2.46xxxx Mhz.  When I changed from UCSCTL2 = FLLD_1 + 74  to UCSCTL2 = FLLD_0 + 149, I get a consistent 4.914890 Mhz MCLK.

Hi G*** ,  ThnQ for the reply Yes I am implementing I2C with an external RTC RX2085 using SDA n SCL lines of MSP430F2274

MSP430F2274 provides UART I2C mode n I am using that do u call it Hardware implementation or Bit banging please tell me and I am not using extra hardware for I2C implementation

I am enocuntering this problem sometimes while receiving charaters

gcgplge said:

Brandon,

When I used msp430x54x_UCS_4, I measured 2.457445Mhz at MCLK which translate to 4.914890 Mhz DCOCLK.  This is as expected but sometimes I see the frequency jump to 2.46xxxx Mhz.  When I changed from UCSCTL2 = FLLD_1 + 74  to UCSCTL2 = FLLD_0 + 149, I get a consistent 4.914890 Mhz MCLK.

Did you get your clocking problem resolved? The above looks appropriate to me.

k thanQ for the links will check thru them .

Is there an explanation both for the problem and the solution?

I am actually using a F5438 and I've run into the same issue. The DCOCLKDIV frequency I measured is 1059kHz instead of the desired 1048kHz: it seems a systematic more than a tolerance error.

The only way to get a reliable clock frequency is by setting the FLL prescaler value to 0. Anyway, I still experience in some sporadic situations an increase of the DCOCLK up to 1052kHz.

Btw, this topic mixes up three different problems and the suggested answer is not a solution for the original one.

cyberstorm said:

 

... this topic mixes up three different problems and the suggested answer is not a solution for the original one.

You are right. There are others with the same problem, and it is still not answered.

There are lots of problems with F54xx. It is quite possible that is caused by an undocumented bug in FLL+.

Did you use any LPM?

Did you use any ISR?

Can you try the same with F54xxA? Free samples are available now.

-- OCY

I dont use any LPM nor ISR. I am just using a very simple test code that  only configures  the UCS and loops in "nop".

Anyway, my (temporary?) solution to the problem is:

1) Clear UCSCTL2.

2) Setup the DCO frequency range select to the needed value.

3)Setup UCSCTL2 with FLL prescaler set to 0 and to the needed multiplicator value.

4)Delay of 32 x 32 / fFLLREF to allow DCO stabilization.

5)Clear any pending DCOFFG and OFIFG faults.

Well, I will eventually try F54xxA samples.

I'm not too surprised about this problem. After thinking a bit about how the FLL works, it is obvious.

The FLL has no memory. It does just detect whether the DCO was too slow or too fast during the last reference interval and depending on this it switches the DCO faster or slower. It does not write down HOW MUCH it was off.

Two DCO taps are 2% to 12% apart. This means it is possible that one time the DCO is just one tick too slow and after the next adjustment it is 12% too fast, then again a bit too slow and again 12% too fast.

The usage of the modulation bits smoothens this a bit, but there's still a good chance of misadjustment.

You'll never get exactly a multiple of the reference, not even in average, except for two conditions: either the desired frequency exactly fits a DCO/MOD setting or it is exactly in the middle of two settings. And only in the first case you'll get one proper frequency, the second one will give it only as average of two frequencies, alternating at 32kHz. Which can also fool your measuring equipment (if possible, use gate counter mode and not pulse timing mode of a frequency counter, and oscilloscopes are completely useless as they do only snapshots and are not telling the 'whole truth')

Also, the constant adjustment (by FLL or the MOD bits) causes a clock jitter which can be unbearable for some applications.

And since the exact values of the DCO taps are device-specific, you can only pray - or use a 'real' clock source such as a high-frequency crystal.

The FLL is the best you can do if you do not have an external quartz ot need to run on very low power, but it is far from being perfect.