I have a new product that uses the LF 32Khz crystal. I looked at the code
that sets the DCO frequency (from the TI examples) and noted the loop exits
when the compare equals the target count. So my question is, is the
granularity of the DCO registers good enough to make sure that the target
count will be met. In other words, you set the capture to read pulses from
the MCLK every 8 ticks of the 32Khz clock, and you have a target value of
x. Can we guarantee that there will be x counts in the compare register at
some setting of the DCO? Obviously my concern in dropping in this code is
the loop never exits so the machine just hangs.
/Bill
--
This message was sent from my Gmail account. You can use either
w...@comcast.net or email to this account directly.
DCO calibration question
Started by ●March 7, 2007
Reply by ●March 7, 20072007-03-07
William Sell wrote:
> I have a new product that uses the LF 32Khz crystal. I looked at the code
> that sets the DCO frequency (from the TI examples) and noted the loop exits
> when the compare equals the target count. So my question is, is the
> granularity of the DCO registers good enough to make sure that the target
> count will be met. In other words, you set the capture to read pulses from
> the MCLK every 8 ticks of the 32Khz clock, and you have a target value of
> x. Can we guarantee that there will be x counts in the compare register at
> some setting of the DCO? Obviously my concern in dropping in this code is
> the loop never exits so the machine just hangs.
>
> /Bill
Hello Bill,
This is not a direct answer to your question but it seems that most
people try to force the DCO to certain frequency using this technique. I
haven't seen any mention in this list about setting the DCO and then
measuring the actual frequency using the 32KHz crystal as the timebase.
This seems to me that the DCO frequency would be more stable (less
jitter) if this approach is used.
Don't know if you can use this approach but maybe it can help someone.
Best regards,
Greg
> I have a new product that uses the LF 32Khz crystal. I looked at the code
> that sets the DCO frequency (from the TI examples) and noted the loop exits
> when the compare equals the target count. So my question is, is the
> granularity of the DCO registers good enough to make sure that the target
> count will be met. In other words, you set the capture to read pulses from
> the MCLK every 8 ticks of the 32Khz clock, and you have a target value of
> x. Can we guarantee that there will be x counts in the compare register at
> some setting of the DCO? Obviously my concern in dropping in this code is
> the loop never exits so the machine just hangs.
>
> /Bill
Hello Bill,
This is not a direct answer to your question but it seems that most
people try to force the DCO to certain frequency using this technique. I
haven't seen any mention in this list about setting the DCO and then
measuring the actual frequency using the 32KHz crystal as the timebase.
This seems to me that the DCO frequency would be more stable (less
jitter) if this approach is used.
Don't know if you can use this approach but maybe it can help someone.
Best regards,
Greg
Reply by ●March 8, 20072007-03-08
--- In m..., "William Sell"
wrote:
>
> I have a new product that uses the LF 32Khz crystal. I looked at
the code
> that sets the DCO frequency (from the TI examples) and noted the
loop exits
> when the compare equals the target count. So my question is, is the
> granularity of the DCO registers good enough to make sure that the
target
> count will be met. In other words, you set the capture to read
pulses from
> the MCLK every 8 ticks of the 32Khz clock, and you have a target
value of
> x. Can we guarantee that there will be x counts in the compare
register at
> some setting of the DCO? Obviously my concern in dropping in this
code is
> the loop never exits so the machine just hangs.
>
> /Bill
>
> --
> This message was sent from my Gmail account. You can use either
> w.sell@... or email to this account directly.
>
>
Hi Bill
We've been doing a bit of work with the DCO for an F148. I found two
tuning approaches on TI's website. The first was a step-by-step
approach where the register values are changed one bit at a time.
Yes, seems to work, but takes a long time to lock up and I agree, I
thought it would never settle at a good tune. I allowed it to run for
so many cycles and then halted the loop.
Another approach is documented in slaa074 and not actually for the
F148. It uses a proportional approach, i.e. change the registers by a
factor proportional to the error. The treatment is quite mathematical
and too clever for what we needed (and me!) so I took the concept and
crafted a bit of code that also seems to work. We save the BSCTL and
DCO reg values and restore them before attempting to tune. Works
well. However, I think there's an oddity in one of the registers -
increasing values fail to have an effect when at high values (0E2h)
and up). There's an upper limit set in the code in slaa074 - search
for "dco_max".
Hope this is some interest, Nick
wrote:
>
> I have a new product that uses the LF 32Khz crystal. I looked at
the code
> that sets the DCO frequency (from the TI examples) and noted the
loop exits
> when the compare equals the target count. So my question is, is the
> granularity of the DCO registers good enough to make sure that the
target
> count will be met. In other words, you set the capture to read
pulses from
> the MCLK every 8 ticks of the 32Khz clock, and you have a target
value of
> x. Can we guarantee that there will be x counts in the compare
register at
> some setting of the DCO? Obviously my concern in dropping in this
code is
> the loop never exits so the machine just hangs.
>
> /Bill
>
> --
> This message was sent from my Gmail account. You can use either
> w.sell@... or email to this account directly.
>
>
Hi Bill
We've been doing a bit of work with the DCO for an F148. I found two
tuning approaches on TI's website. The first was a step-by-step
approach where the register values are changed one bit at a time.
Yes, seems to work, but takes a long time to lock up and I agree, I
thought it would never settle at a good tune. I allowed it to run for
so many cycles and then halted the loop.
Another approach is documented in slaa074 and not actually for the
F148. It uses a proportional approach, i.e. change the registers by a
factor proportional to the error. The treatment is quite mathematical
and too clever for what we needed (and me!) so I took the concept and
crafted a bit of code that also seems to work. We save the BSCTL and
DCO reg values and restore them before attempting to tune. Works
well. However, I think there's an oddity in one of the registers -
increasing values fail to have an effect when at high values (0E2h)
and up). There's an upper limit set in the code in slaa074 - search
for "dco_max".
Hope this is some interest, Nick
Reply by ●March 8, 20072007-03-08
> I have a new product that uses the LF 32Khz crystal.
I looked at the code
> that sets the DCO frequency (from the TI examples) and noted the loop exits
> when the compare equals the target count. So my question is, is the
> granularity of the DCO registers good enough to make sure that the target
> count will be met. In other words, you set the capture to read pulses from
> the MCLK every 8 ticks of the 32Khz clock, and you have a target value of
> x. Can we guarantee that there will be x counts in the compare register at
> some setting of the DCO? Obviously my concern in dropping in this code is
> the loop never exits so the machine just hangs.
>
> /Bill
>
Last year I've implemented a DCO calibration and I've got the same problem you described above.
The time for calibration has varied vary much because the counter hasn't reached exactly the desired value.
My remedy was to allow some tolerance for the calibration routine.
Now the DCO calibration will be finished in a defined time.
(First setup needs a little bit more time, but recalibration is normally done in one calibration step.)
Regards, Florian
> that sets the DCO frequency (from the TI examples) and noted the loop exits
> when the compare equals the target count. So my question is, is the
> granularity of the DCO registers good enough to make sure that the target
> count will be met. In other words, you set the capture to read pulses from
> the MCLK every 8 ticks of the 32Khz clock, and you have a target value of
> x. Can we guarantee that there will be x counts in the compare register at
> some setting of the DCO? Obviously my concern in dropping in this code is
> the loop never exits so the machine just hangs.
>
> /Bill
>
Last year I've implemented a DCO calibration and I've got the same problem you described above.
The time for calibration has varied vary much because the counter hasn't reached exactly the desired value.
My remedy was to allow some tolerance for the calibration routine.
Now the DCO calibration will be finished in a defined time.
(First setup needs a little bit more time, but recalibration is normally done in one calibration step.)
Regards, Florian
Reply by ●March 8, 20072007-03-08
If you look at the data sheet of the chip you are using, you can find
a parameter called SDCO. This is the ratio of the frequencies between
adjacent DCO settings. Typically, the MAX SDCO is 1.16. That
translates to about 16%. There are 32 different MOD settings, thus
the granularity is about 16% / 32 = ~0.5%.
If the target value is 200 or less, the 0.5% granularity is good
enough. (200 * 0.5% = 1). If the target value is much larger than
200, it may never match exactly (at least in principle). But the DCO
frequency wobbles all the time and that helps you to get an exact
match if it tries repeatedly.
--- In m..., "kitpicker" wrote:
>
> --- In m..., "William Sell"
> wrote:
> >
> > I have a new product that uses the LF 32Khz crystal. I looked at
> the code
> > that sets the DCO frequency (from the TI examples) and noted the
> loop exits
> > when the compare equals the target count. So my question is, is
the
> > granularity of the DCO registers good enough to make sure that
the
> target
> > count will be met. In other words, you set the capture to read
> pulses from
> > the MCLK every 8 ticks of the 32Khz clock, and you have a target
> value of
> > x. Can we guarantee that there will be x counts in the compare
> register at
> > some setting of the DCO? Obviously my concern in dropping in
this
> code is
> > the loop never exits so the machine just hangs.
> >
> > /Bill
> >
> > --
> > This message was sent from my Gmail account. You can use either
> > w.sell@ or email to this account directly.
> >
> >
> >
> >
> Hi Bill
>
> We've been doing a bit of work with the DCO for an F148. I found
two
> tuning approaches on TI's website. The first was a step-by-step
> approach where the register values are changed one bit at a time.
> Yes, seems to work, but takes a long time to lock up and I agree, I
> thought it would never settle at a good tune. I allowed it to run
for
> so many cycles and then halted the loop.
> Another approach is documented in slaa074 and not actually for the
> F148. It uses a proportional approach, i.e. change the registers by
a
> factor proportional to the error. The treatment is quite
mathematical
> and too clever for what we needed (and me!) so I took the concept
and
> crafted a bit of code that also seems to work. We save the BSCTL
and
> DCO reg values and restore them before attempting to tune. Works
> well. However, I think there's an oddity in one of the registers -
> increasing values fail to have an effect when at high values (0E2h)
> and up). There's an upper limit set in the code in slaa074 - search
> for "dco_max".
>
> Hope this is some interest, Nick
>
a parameter called SDCO. This is the ratio of the frequencies between
adjacent DCO settings. Typically, the MAX SDCO is 1.16. That
translates to about 16%. There are 32 different MOD settings, thus
the granularity is about 16% / 32 = ~0.5%.
If the target value is 200 or less, the 0.5% granularity is good
enough. (200 * 0.5% = 1). If the target value is much larger than
200, it may never match exactly (at least in principle). But the DCO
frequency wobbles all the time and that helps you to get an exact
match if it tries repeatedly.
--- In m..., "kitpicker" wrote:
>
> --- In m..., "William Sell"
> wrote:
> >
> > I have a new product that uses the LF 32Khz crystal. I looked at
> the code
> > that sets the DCO frequency (from the TI examples) and noted the
> loop exits
> > when the compare equals the target count. So my question is, is
the
> > granularity of the DCO registers good enough to make sure that
the
> target
> > count will be met. In other words, you set the capture to read
> pulses from
> > the MCLK every 8 ticks of the 32Khz clock, and you have a target
> value of
> > x. Can we guarantee that there will be x counts in the compare
> register at
> > some setting of the DCO? Obviously my concern in dropping in
this
> code is
> > the loop never exits so the machine just hangs.
> >
> > /Bill
> >
> > --
> > This message was sent from my Gmail account. You can use either
> > w.sell@ or email to this account directly.
> >
> >
> >
> >
> Hi Bill
>
> We've been doing a bit of work with the DCO for an F148. I found
two
> tuning approaches on TI's website. The first was a step-by-step
> approach where the register values are changed one bit at a time.
> Yes, seems to work, but takes a long time to lock up and I agree, I
> thought it would never settle at a good tune. I allowed it to run
for
> so many cycles and then halted the loop.
> Another approach is documented in slaa074 and not actually for the
> F148. It uses a proportional approach, i.e. change the registers by
a
> factor proportional to the error. The treatment is quite
mathematical
> and too clever for what we needed (and me!) so I took the concept
and
> crafted a bit of code that also seems to work. We save the BSCTL
and
> DCO reg values and restore them before attempting to tune. Works
> well. However, I think there's an oddity in one of the registers -
> increasing values fail to have an effect when at high values (0E2h)
> and up). There's an upper limit set in the code in slaa074 - search
> for "dco_max".
>
> Hope this is some interest, Nick
>
Reply by ●March 9, 20072007-03-09
Nick,
Perhaps the oddity is default setting of the DCOCTL and BSCTL on PUC. I
made the mistake (thanks OCY for pointing this out) that I was or'ing in the
values to the registers, so the upper end made no difference, these bits
were already set.
/Bill
--
This message was sent from my Gmail account. You can use either
w...@comcast.net or email to this account directly.
Perhaps the oddity is default setting of the DCOCTL and BSCTL on PUC. I
made the mistake (thanks OCY for pointing this out) that I was or'ing in the
values to the registers, so the upper end made no difference, these bits
were already set.
/Bill
--
This message was sent from my Gmail account. You can use either
w...@comcast.net or email to this account directly.
Reply by ●March 12, 20072007-03-12
--- In m..., "William Sell"
wrote:
>
> Nick,
> Perhaps the oddity is default setting of the DCOCTL and BSCTL on
PUC. I
> made the mistake (thanks OCY for pointing this out) that I was
or'ing in the
> values to the registers, so the upper end made no difference, these
bits
> were already set.
>
> /Bill
>
> --
> This message was sent from my Gmail account. You can use either
> w.sell@... or email to this account directly.
>
>
Bill
Your comment encouraged me to have another look at the datasheet. In
the section on the Basic Clock Module, under the description of the
DCO control reg, there's a comment "Not usable when DCOx=7". In other
words, the modulator bits have no effect when the DCO bits have
already been incremented to 7. Thniking about it, it does make sense.
The mod bits define how many times in 32 that the "DCO frequency + 1"
is inserted in the clock stream. If the DCO is already at 7 and
cannot be further incremented, there isn't a DCO+1 value to use. This
explains why the value 0xE2 is an upper limit in the TI app note and
also explains why I see no change in frequency when the entire DCOCTL
reg is incremented above 0xE0. Thanks, without your comment the penny
would never have dropped.
Nick
wrote:
>
> Nick,
> Perhaps the oddity is default setting of the DCOCTL and BSCTL on
PUC. I
> made the mistake (thanks OCY for pointing this out) that I was
or'ing in the
> values to the registers, so the upper end made no difference, these
bits
> were already set.
>
> /Bill
>
> --
> This message was sent from my Gmail account. You can use either
> w.sell@... or email to this account directly.
>
>
Bill
Your comment encouraged me to have another look at the datasheet. In
the section on the Basic Clock Module, under the description of the
DCO control reg, there's a comment "Not usable when DCOx=7". In other
words, the modulator bits have no effect when the DCO bits have
already been incremented to 7. Thniking about it, it does make sense.
The mod bits define how many times in 32 that the "DCO frequency + 1"
is inserted in the clock stream. If the DCO is already at 7 and
cannot be further incremented, there isn't a DCO+1 value to use. This
explains why the value 0xE2 is an upper limit in the TI app note and
also explains why I see no change in frequency when the entire DCOCTL
reg is incremented above 0xE0. Thanks, without your comment the penny
would never have dropped.
Nick
Reply by ●March 12, 20072007-03-12
Nick,
Your original concern about the granularity is valid.
Assuming that the DCO frequency of adjacent settings has a
granularity of 0.5% and your target x is about 200, then you can get
the exact x you want by tweaking the DCO. But if your target x is
about 400, you should exit the tweaking when you get either x or x+1.
If your target x is about 600, you should exit when you get x-1, x,
or x+1.
--- In m..., "kitpicker" wrote:
>
> --- In m..., "William Sell"
> wrote:
> >
> > Nick,
> > Perhaps the oddity is default setting of the DCOCTL and BSCTL on
> PUC. I
> > made the mistake (thanks OCY for pointing this out) that I was
> or'ing in the
> > values to the registers, so the upper end made no difference,
these
> bits
> > were already set.
> >
> > /Bill
> >
> > --
> > This message was sent from my Gmail account. You can use either
> > w.sell@ or email to this account directly.
> >
> >
> >
> >
> Bill
>
> Your comment encouraged me to have another look at the datasheet.
In
> the section on the Basic Clock Module, under the description of the
> DCO control reg, there's a comment "Not usable when DCOx=7". In
other
> words, the modulator bits have no effect when the DCO bits have
> already been incremented to 7. Thniking about it, it does make
sense.
> The mod bits define how many times in 32 that the "DCO frequency +
1"
> is inserted in the clock stream. If the DCO is already at 7 and
> cannot be further incremented, there isn't a DCO+1 value to use.
This
> explains why the value 0xE2 is an upper limit in the TI app note
and
> also explains why I see no change in frequency when the entire
DCOCTL
> reg is incremented above 0xE0. Thanks, without your comment the
penny
> would never have dropped.
>
> Nick
>
Your original concern about the granularity is valid.
Assuming that the DCO frequency of adjacent settings has a
granularity of 0.5% and your target x is about 200, then you can get
the exact x you want by tweaking the DCO. But if your target x is
about 400, you should exit the tweaking when you get either x or x+1.
If your target x is about 600, you should exit when you get x-1, x,
or x+1.
--- In m..., "kitpicker" wrote:
>
> --- In m..., "William Sell"
> wrote:
> >
> > Nick,
> > Perhaps the oddity is default setting of the DCOCTL and BSCTL on
> PUC. I
> > made the mistake (thanks OCY for pointing this out) that I was
> or'ing in the
> > values to the registers, so the upper end made no difference,
these
> bits
> > were already set.
> >
> > /Bill
> >
> > --
> > This message was sent from my Gmail account. You can use either
> > w.sell@ or email to this account directly.
> >
> >
> >
> >
> Bill
>
> Your comment encouraged me to have another look at the datasheet.
In
> the section on the Basic Clock Module, under the description of the
> DCO control reg, there's a comment "Not usable when DCOx=7". In
other
> words, the modulator bits have no effect when the DCO bits have
> already been incremented to 7. Thniking about it, it does make
sense.
> The mod bits define how many times in 32 that the "DCO frequency +
1"
> is inserted in the clock stream. If the DCO is already at 7 and
> cannot be further incremented, there isn't a DCO+1 value to use.
This
> explains why the value 0xE2 is an upper limit in the TI app note
and
> also explains why I see no change in frequency when the entire
DCOCTL
> reg is incremented above 0xE0. Thanks, without your comment the
penny
> would never have dropped.
>
> Nick
>
