Great! Thanks for the help.
--- In msp430@msp4..., Onestone <onestone@b...> wrote:
> The DCO is MOST susceptible to drift with voltage
level, not
> temperature. So check this out first. Try and run your software
FLL
> during the receive cycle if you can, not just
periodically, but
every
> time you need the DCO. This should be possible
even at the
baudrate
> you're running. I would say that you are
probably borderline for
what is
> feasible using the soft FLL and DCO. However if
you have no other
> interrupts running at this time you could implement a comms method
that
> does not rely on precise timing such as a pulse
length system. You
have
> enough clock cycles to handle this. Perhaps the
simplest way to do
this
> is to send every pulse as either a short/long or a
long/short. a
bit
> like the old trinary codes beloved by remote key
fobs. one
sequence = 0
> the other = 1, the sum of the period is the same,
104 clock ticks
for
> 57600 baud, which gives you plenty of time to
respond to the
interrupts.
> ie you bit bang the thing. Timing can drift all
over the plac
ethen,
> without affecting our comms link. I use this
method on all very
low
> power designs, where I need high speed comms, but
can't afford the
power
> budget for a fast crystal..
>
> Cheers
>
> Al
>
> ucfengineer wrote:
>
> >Subject: Problem with using DCO (6MHz) as UART Clock.
> >
> >Greetings:
> >
> >I'm having an intermittent problem using the DCO to drive my UART
> >clock. In my particular application, I have 2 MSP430F149 chips
> >transfer data between them using the USART in UART mode. They are
> >both configured to use the internal DCO Clock, using an external
> >resistor of 100k on Rosc to produce a frequency of 6MHz. In
order to
> >attain this frequency, the chips use an
external 32.768KHz
crystal for
> >calibration (App Note slaa074.pdf). They are
also configured to
turn
> >on the DCO Clock when the start bit is
received, and then shut it
off
> >after the byte has been received (on the next
subsequent serial
> >receive interrupt). The configured baud rate is 57600.
> >
> >Register settings:
> > U0BR1 = 0x00; // 6 Mhz
> > U0BR0 = 0x68;
> > U0MCTL = 0x20;
> >
> >For the most part, I am able to transfer data in 10 - 100 byte
chucks
> >between the two without problem. However,
every now and then it
will
> >fail. When it fails, the receiver sees more
than one start bit
in a
> >row, and the data gets corrupted. It usually
receives the first
and
> >maybe the second byte ok, but then the rest of
the stream seems
out of
> >sync.
> >
> >I think the problem is that they are both using their internal
DCO,
> >which seems to vary in frequency (with respect
to the 32 KHz
> >reference). I did some measurements and noticed that per one
period
> >of the 32Khz reference, I was seeing a
variation of up to 4 in the
> >number of cycles of the DCO Clock. This, when scaled up, puts the
> >frequency oscillation between 98.304 and 131.072 KHz. There is
no big
> >temperature variation during this time, so I
don't know why the
DCO
> >varies so much.
> >
> >I've thought about using the 32Khz to operate at a 9600 baud
rate, but
> >I would really like to be up in the 57600
range... which
wouldn't be
> >possible with that frequency.
> >
> >Is there something I can do to make this work?
> >
> >Any and all suggestions/comments welcome!
> >
> >Jeff
> >
> >
> >
> >
> >
> >
> >
> >.
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
The DCO is MOST susceptible to drift with voltage level, not
temperature. So check this out first. Try and run your software FLL
during the receive cycle if you can, not just periodically, but every
time you need the DCO. This should be possible even at the baudrate
you're running. I would say that you are probably borderline for what is
feasible using the soft FLL and DCO. However if you have no other
interrupts running at this time you could implement a comms method that
does not rely on precise timing such as a pulse length system. You have
enough clock cycles to handle this. Perhaps the simplest way to do this
is to send every pulse as either a short/long or a long/short. a bit
like the old trinary codes beloved by remote key fobs. one sequence = 0
the other = 1, the sum of the period is the same, 104 clock ticks for
57600 baud, which gives you plenty of time to respond to the interrupts.
ie you bit bang the thing. Timing can drift all over the plac ethen,
without affecting our comms link. I use this method on all very low
power designs, where I need high speed comms, but can't afford the power
budget for a fast crystal..
Cheers
Al
ucfengineer wrote:
>Subject: Problem with using DCO (6MHz) as UART
Clock.
>
>Greetings:
>
>I'm having an intermittent problem using the DCO to drive my UART
>clock. In my particular application, I have 2 MSP430F149 chips
>transfer data between them using the USART in UART mode. They are
>both configured to use the internal DCO Clock, using an external
>resistor of 100k on Rosc to produce a frequency of 6MHz. In order to
>attain this frequency, the chips use an external 32.768KHz crystal for
>calibration (App Note slaa074.pdf). They are also configured to turn
>on the DCO Clock when the start bit is received, and then shut it off
>after the byte has been received (on the next subsequent serial
>receive interrupt). The configured baud rate is 57600.
>
>Register settings:
> U0BR1 = 0x00; // 6 Mhz
> U0BR0 = 0x68;
> U0MCTL = 0x20;
>
>For the most part, I am able to transfer data in 10 - 100 byte chucks
>between the two without problem. However, every now and then it will
>fail. When it fails, the receiver sees more than one start bit in a
>row, and the data gets corrupted. It usually receives the first and
>maybe the second byte ok, but then the rest of the stream seems out of
>sync.
>
>I think the problem is that they are both using their internal DCO,
>which seems to vary in frequency (with respect to the 32 KHz
>reference). I did some measurements and noticed that per one period
>of the 32Khz reference, I was seeing a variation of up to 4 in the
>number of cycles of the DCO Clock. This, when scaled up, puts the
>frequency oscillation between 98.304 and 131.072 KHz. There is no big
>temperature variation during this time, so I don't know why the DCO
>varies so much.
>
>I've thought about using the 32Khz to operate at a 9600 baud rate, but
>I would really like to be up in the 57600 range... which wouldn't be
>possible with that frequency.
>
>Is there something I can do to make this work?
>
>Any and all suggestions/comments welcome!
>
>Jeff
>
>
>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Reply by ucfengineer●August 25, 20052005-08-25
Subject: Problem with using DCO (6MHz) as UART Clock.
Greetings:
I'm having an intermittent problem using the DCO to drive my UART
clock. In my particular application, I have 2 MSP430F149 chips
transfer data between them using the USART in UART mode. They are
both configured to use the internal DCO Clock, using an external
resistor of 100k on Rosc to produce a frequency of 6MHz. In order to
attain this frequency, the chips use an external 32.768KHz crystal for
calibration (App Note slaa074.pdf). They are also configured to turn
on the DCO Clock when the start bit is received, and then shut it off
after the byte has been received (on the next subsequent serial
receive interrupt). The configured baud rate is 57600.
Register settings:
U0BR1 = 0x00; // 6 Mhz
U0BR0 = 0x68;
U0MCTL = 0x20;
For the most part, I am able to transfer data in 10 - 100 byte chucks
between the two without problem. However, every now and then it will
fail. When it fails, the receiver sees more than one start bit in a
row, and the data gets corrupted. It usually receives the first and
maybe the second byte ok, but then the rest of the stream seems out of
sync.
I think the problem is that they are both using their internal DCO,
which seems to vary in frequency (with respect to the 32 KHz
reference). I did some measurements and noticed that per one period
of the 32Khz reference, I was seeing a variation of up to 4 in the
number of cycles of the DCO Clock. This, when scaled up, puts the
frequency oscillation between 98.304 and 131.072 KHz. There is no big
temperature variation during this time, so I don't know why the DCO
varies so much.
I've thought about using the 32Khz to operate at a 9600 baud rate, but
I would really like to be up in the 57600 range... which wouldn't be
possible with that frequency.
Is there something I can do to make this work?
Any and all suggestions/comments welcome!
Jeff