Everyone,

In an MSP430F149-based design, I need to ditch my 8MHz XTAL from XT2
while maintaining a clock of around 8 MHz from the DCO for MCLK. I
still have a 32.768kHx XTAL on XT1 for clocking critical timing stuff
(such as sample rate).

I have a 100K 1% external resistor on P2.5, which according to the
user guide will allow me to boost the DCO upto 10MHz, with a pretty
good temperature coefficient (device will be working around room
temperature anyway). Supply voltage is regulated. This to me implies
that if I could tune the DCO at startup with the accurate 32.768kHz
clock, the clock will not drift too much during operation.

I obviously want to do something quite similar to what is described in
application note "Controlling the DCO Frequency of the MSP430x11x"
(slaa074), such as measuring the frequency difference by running a
capture/compare timer on the DCO and capturing the 32kHz clock. 

However, differently: I am using an external resistor, and I would
like to  make a generic function to set any frequency available over
the whole DCO range (varying the DCO parameters to get near to the
desired set frequency). In this application there is not really a need
for tuning the clock by DCO modulation, and I also don't like the
jitter this will introduce. So once the clock is set it will be left
free-running.

Besides suggestions about my general approach, I am specifically
looking for a formula or table that lists the nominal DCO frequency in
function of the DCO registers. In the user guide there is a vague
staircase-like graph without any specific values, and in the
device-specific datasheet there is a table of typical and min/max
values but only for a small subset of the possible values and not
including the effects of using an external resistor. Can anybody point
me to this info? 

greetings,
Tom

This is called a software frequency Locked Loop, or FLL. Ti have app 
notes on locking the DCO to the watch crystal in software. This is by no 
means good enough accuracy wise for anything I'd deem critical timing.

tom_torfs wrote:

> 
> Everyone,
> 
> In an MSP430F149-based design, I need to ditch my 8MHz XTAL from XT2
> while maintaining a clock of around 8 MHz from the DCO for MCLK. I
> still have a 32.768kHx XTAL on XT1 for clocking critical timing stuff
> (such as sample rate).
> 
> I have a 100K 1% external resistor on P2.5, which according to the
> user guide will allow me to boost the DCO upto 10MHz, with a pretty
> good temperature coefficient (device will be working around room
> temperature anyway). Supply voltage is regulated. This to me implies
> that if I could tune the DCO at startup with the accurate 32.768kHz
> clock, the clock will not drift too much during operation.
> 
> I obviously want to do something quite similar to what is described in
> application note "Controlling the DCO Frequency of the
MSP430x11x"
> (slaa074), such as measuring the frequency difference by running a
> capture/compare timer on the DCO and capturing the 32kHz clock. 
> 
> However, differently: I am using an external resistor, and I would
> like to  make a generic function to set any frequency available over
> the whole DCO range (varying the DCO parameters to get near to the
> desired set frequency). In this application there is not really a need
> for tuning the clock by DCO modulation, and I also don't like the
> jitter this will introduce. So once the clock is set it will be left
> free-running.

bad move if you want any kind or accuracy at all.

> 
> Besides suggestions about my general approach, I am specifically
> looking for a formula or table that lists the nominal DCO frequency in
> function of the DCO registers. In the user guide there is a vague
> staircase-like graph without any specific values, and in the
> device-specific datasheet there is a table of typical and min/max
> values but only for a small subset of the possible values and not
> including the effects of using an external resistor. Can anybody point

Why bother trying to do this. Implement the FLL and you can write a 
routine that increase the DCO in fine or coarse stages to meet any 
frequency you need. Coarse stages are those requiring DCo register 
changes, fine changes are those to tweak the Do to its most accurate. Of 
course you could also have a table of approximate DCO reg vs frequency, 
but thsi assumes specific voltage supply and temperature conditions. The 
temperature in my house today has varied from 7C to 38C.

Al

> me to this info? 
> 
> greetings,
> Tom
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Hi,

> This is called a software frequency Locked Loop,
or FLL. Ti have
app 
> notes on locking the DCO to the watch crystal in
software.
> This is by no means good enough accuracy wise for anything I'd deem
critical timing.

This will only be sourcing the not-so-critical MCLK and SPI, as stated
all critical timing stuff will run directly from the watch crystal.
The DCO temperature coefficient with an external resistor is good
enough ("Using an external ROSC reduces the DCO temperature
coefficient to approximately 0.05%/C.") and supply voltage is
regulated. By calibrating against the 32kHz clock I can eliminate the
remaining unknown factor, process variations, to end up with a clock
that should be close enough to my set frequency for the application.

> > Besides suggestions about my general
approach, I am specifically
> > looking for a formula or table that lists the nominal DCO 
> > frequency in
> > function of the DCO registers.

> Why bother trying to do this. Implement the FLL
and you can write a 
> routine that increase the DCO in fine or coarse stages to meet any 
> frequency you need. Coarse stages are those requiring DCo register 
> changes, fine changes are those to tweak the Do to its most
accurate.

Yes, but from the staircase graph in the user guide I am a bit
concerned the different DCO ranges might overlap, so the clock
frequency is not a monotonic function of (DCO,RSEL). This could cause
a regulating loop to get confused. If TI would have published
somewhere typical/min/max values for the whole range of settings,
including when using external resistor, this would allow me to see if
this situation can actually occur or not. It would also give me an
idea of the accuracy I could obtain.

greetings,
Tom

tom_torfs wrote:
> 
> Hi,
> 
> 
>>This is called a software frequency Locked Loop, or FLL. Ti have
> 
> app 
> 
>>notes on locking the DCO to the watch crystal in software.
>>This is by no means good enough accuracy wise for anything I'd deem
> 
> critical timing.
> 
> This will only be sourcing the not-so-critical MCLK and SPI, as stated
> all critical timing stuff will run directly from the watch crystal.
> The DCO temperature coefficient with an external resistor is good
> enough ("Using an external ROSC reduces the DCO temperature
> coefficient to approximately 0.05%/C.") and supply voltage is
> regulated. By calibrating against the 32kHz clock I can eliminate the
> remaining unknown factor, process variations, to end up with a clock
> that should be close enough to my set frequency for the application.

Obviously then you don't have any critical timing functions, as the 
watch crystal is too crude for this, except of course for use as an RTC. 
You can't precision time anything with it, and need to account for sync 
errors if using the DCO for MCLK, and the watch crustal for slower 
function. A fast DCO locked to the watch crystal gives better timing 
resolution than the watch crystal alone.

> 
> 
>>>Besides suggestions about my general approach, I am specifically
>>>looking for a formula or table that lists the nominal DCO 
>>>frequency in
>>>function of the DCO registers.
> 
> 
>>Why bother trying to do this. Implement the FLL and you can write a 
>>routine that increase the DCO in fine or coarse stages to meet any 
>>frequency you need. Coarse stages are those requiring DCo register 
>>changes, fine changes are those to tweak the Do to its most
> 
> accurate.
> 
> Yes, but from the staircase graph in the user guide I am a bit
> concerned the different DCO ranges might overlap, so the clock
> frequency is not a monotonic function of (DCO,RSEL). 

The DCO ranges will overlap, no doubt about it, but it is an easy thing 
to adjust in software. Equally there will be a staircase effect to the 
actual frequencies for any DCO setting. That is what the modulator is for.

This could cause
> a regulating loop to get confused.

You can easily account for this in software. The overlapping is 
reasonably broad. It isn't difficult to write a piece of self 
characterising code that stores the DCO characterisitics in a table. 
This is better than trying to find some mean values that suit all parts. 
The manufacturing differences between devices are reasonably large.

  If TI would have published
> somewhere typical/min/max values for the whole
range of settings,

They do. They list nominal frequency plus tolerance for specific 
conditions, then give the range of temperature and voltage related drift.

> including when using external resistor, this would
allow me to see if
> this situation can actually occur or not. It would also give me an
> idea of the accuracy I could obtain.

There are too many variables for this to be practical. The DCO is 
extremely crude as an oscillator. This is why the modulator is provided

Al

Hi,

I'm somewhat curious as to what the definition of "critical
timing" 
is in terms of embedded systems.  It seems you are implying that 
because this guy has timing requirements that are probably in the 
tenths of seconds or more he has no real citical timing in his 
system.  Is there a maximum time requirement a process must have 
before it is considered critical? Seems odd.

Robert

No, to me critical timing implies that the timing must be as accurate as 
possible, as in timing a process, pulse etc. It also implies some degree 
of repeatability that has minimum jitter. These conditions suggest that 
a 32768Hz clock is insufficient to meet these needs, and that the DCO, 
suitably locked to the crystal offers a better source for critical timing.

Obviously 'critical timing' is a vague term. It means different things

to different people, but where you are dealing with a design that, on 
the one hand is seeking an 8MHz clock, giving 125nsec resolution, and on 
the other is using a watch crystal with 30517 nsec resolution the former 
offers the best option for anything that might be deemed critical within 
the scope of that design.

As you suggest it is a vague requirement. To me critical timing systems 
(MSP430) use an 8MHz crystal that has 5ppm drift, the lowest tempco 
possible, and the lowest possible initial error, or, as in one system, a 
similar spec 100MHz crystal using PECL counters, where the MSP430s only 
handle the data processing, and fine timing.

Al

Robert wrote:

> 
> Hi,
> 
> I'm somewhat curious as to what the definition of "critical
timing" 
> is in terms of embedded systems.  It seems you are implying that 
> because this guy has timing requirements that are probably in the 
> tenths of seconds or more he has no real citical timing in his 
> system.  Is there a maximum time requirement a process must have 
> before it is considered critical? Seems odd.
> 
> Robert
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

> > This will only be sourcing the
not-so-critical MCLK and SPI, as
stated
> > all critical timing stuff will run directly
from the watch
crystal.

> Obviously then you don't have any critical
timing functions, as the 
> watch crystal is too crude for this, except of course for use as an
RTC

OK now we're discussing semantics. By 'critical timing' I mean
things
like the data sample rate. This has to stay within let's say 0.5% of
its nominal value or my post-processing digital filters, FFT etc. will
be too far off their nominal frequencies. The +/-20ppm offered by a
properly matched watch crystal is certainly sufficient for achieving
this.

Thanks for confirming that overlap is possible. I guess I will let the
software build a table of the DCO characteristics dynamically at
startup and regulate based on that.

greetings,
Tom

I do a lot of sampling at both 8kHz and 44200Hz. In either case I aim 
for better than 0.1% sample rate accuracy. It is possible to pick the 
difference, and observe it. especially in a large FFT.

tom_torfs wrote:

> 
>>>This will only be sourcing the not-so-critical MCLK and SPI, as
> 
> stated
> 
>>>all critical timing stuff will run directly from the watch
> 
> crystal.
> 
> 
>>Obviously then you don't have any critical timing functions, as the

>>watch crystal is too crude for this, except of course for use as an
> 
> RTC
> 
> OK now we're discussing semantics. By 'critical timing' I
mean things
> like the data sample rate. This has to stay within let's say 0.5% of
> its nominal value or my post-processing digital filters, FFT etc. will
> be too far off their nominal frequencies. The +/-20ppm offered by a
> properly matched watch crystal is certainly sufficient for achieving
> this.

I use the Dallas ultra stable crystals for my RTC, 1ppm, 1 minute/year. 
But that is on an automated billing system that needs to be certified.

> 
> Thanks for confirming that overlap is possible. I guess I will let the
> software build a table of the DCO characteristics dynamically at
> startup and regulate based on that.

This would be my recommended approach. It gets rid of the need for a 
calibration cycle, and, if you have an RTC, allows you to periodically 
update the table if necessary.

Al

> 
> greetings,
> Tom
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
>