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

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
>
>
>
> 
>
>
>
>
>  
>

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
> >
> >
> >
> > 
> >
> >
> >
> >
> >  
> >