My two cents: here's a way to tell if it's hardware of software. In the place where you decide what character to send, replace that line with a line that always generates the same character. If your code always sends the fixed character with no errors, you have an intermittent software bug. If you still get errors after time, you have a hardware problem.

Lloyd

Beginning Microcontrollers with the MSP430

Had a similar problem. Are you using LPM3? This will stop the UART!

M.

can you attach a data monitor to the comms line so you can see if the MSP
is actually generating invalid chars?

Does it go back to working OK after the problem, ir is it stuck in a
broken state?

D
In article , m...@yahoo.co.in (merapcb)
wrote:

> *From:* "merapcb"
> *To:* m...
> *Date:* Thu, 04 Feb 2010 04:27:22 -0000
>
> In a board I have, there is a UART that is used to send data to a
> PC. When connected and running, sending data every few seconds,
> after about 1-1.5 hours, the data is corrupted (meaning one or more
> bytes get corrupted or missing). I have another board (which I did
> not make) where it runs fine for very long time. My question is,
> what can be the cause for this time-based corruption? The code I am
> sure is fine (very simple and as I said running fine on other
> board). From a hardware perspective it is just a micro (MSP430F169)
> connected to a MAX3232 and then to a PC.
>
> Thanks for your views on this
> --
> *Included Files:*
> am2file:001-HTML_Message.html

merapcb

Not sure if the data stays corrupted - or are you just seeing a glitch after
one hour of operation?

I'll assume that the software is OK - since you claim it runs fine on
another board.

Since this is a home-made board - I'd start looking at the board layout and
components first.

On the board layout:
Check that your traces are good - and you have no cold solder joints.
Double check your power supply voltages, ground planes, etc.

For components:
I'll assume that the crystal is stable and the MSP430 didn't suffer from
ESD.
The Max3232 is a pretty tough chip - about the only thing that can go wrong
with it are the charge/pump caps or poor power supply decoupling or the
voltage regulator drooping.
(1) If the charge pump caps are marginal (ie/ ESR changes drastically at
temp) then try to double the values to reduce the ripple.
(2) Make sure you have adequate power supply decoupling.
(3) If the voltage regulator drops too far below 2.7v then the PC may not
interpret the serial data correctly.

If you think heat is still the culprit - try a heat lamp and cold spray to
isolate a bad trace or component.

The other thing to look for on RS232 is the length of the cable (less than
50 feet) and to keep the cable away from motors, etc.

That's all I can think of.

Good luck,

Juan Carlos
On Wed, Feb 3, 2010 at 11:27 PM, merapcb wrote:

>
> In a board I have, there is a UART that is used to send data to a PC. When
> connected and running, sending data every few seconds, after about 1-1.5
> hours, the data is corrupted (meaning one or more bytes get corrupted or
> missing). I have another board (which I did not make) where it runs fine for
> very long time. My question is, what can be the cause for this time-based
> corruption? The code I am sure is fine (very simple and as I said running
> fine on other board). From a hardware perspective it is just a micro
> (MSP430F169) connected to a MAX3232 and then to a PC.
>
> Thanks for your views on this
>
>
>

merapcb wrote:
> OK I will try to be more exact. There is no watch crystal, only the main 6MHz one. So UART is derived from MCLK only. Hope that further clarifies.
>
> Furthermore, the same code is running successfully on another (i.e. commercially purchased) board without any problems.
>
> My thinking is maybe it is some capacitance building up over time, but not sure if it is logical.
>
Crystals are stable in parts per million, if your crystal is stable, and
it is pretty hard not to make it so, it is not frequency. I take it you
don't have a freq meter to check. Have you checked the divisor you are
using? 6^6 / BaudRate. Maybe it wrong and right on the edge, but I'd
think that very unlikely. What memory are you reading from? Was it a
local created on the stack? Do you write from this buffer from
interrupts or hang in a loop while watching the IFGx?

Best, Dan.

OK I will try to be more exact. There is no watch crystal, only the main 6MHz one. So UART is derived from MCLK only. Hope that further clarifies.

Furthermore, the same code is running successfully on another (i.e. commercially purchased) board without any problems.

My thinking is maybe it is some capacitance building up over time, but not sure if it is logical.
--- In m..., Dan Bloomquist wrote:
>
> merapcb wrote:
> > Using the crystal....
> >
>
> Which crystal, how? Yc's question is as valid as it gets. If a watch, do
> you recalibrate on occasion, or just use ACLK to drive your uart? If you
> don't recal, is the temp/voltage changing much? Personally, I set the
> MCLK from the watch and use that for the uart. Means my timers are also
> calabrated. No squeaks required. So, how??? If this is not a timing
> problem, you can move on with more information than, 'the crystal'. But
> if not a timing problem, now it gets interesting....
>
> Best, Dan.
> (And why I named my thread: Why won't my project work!!)
> Are you getting this?
>

merapcb wrote:
> Using the crystal....
>

Which crystal, how? Yc's question is as valid as it gets. If a watch, do
you recalibrate on occasion, or just use ACLK to drive your uart? If you
don't recal, is the temp/voltage changing much? Personally, I set the
MCLK from the watch and use that for the uart. Means my timers are also
calabrated. No squeaks required. So, how??? If this is not a timing
problem, you can move on with more information than, 'the crystal'. But
if not a timing problem, now it gets interesting....

Best, Dan.
(And why I named my thread: Why won't my project work!!)
Are you getting this?

Using the crystal....
--- In m..., "old_cow_yellow" wrote:
>
> Do you use crystal or DCO to generate the clock for the on-chip UART?
> The DCO frequency may drift over time.
>

Do you use crystal or DCO to generate the clock for the on-chip UART?
The DCO frequency may drift over time.

--- In m..., "merapcb" wrote:
> In a board I have, there is a UART that is used to send data to a PC. When connected and running, sending data every few seconds, after about 1-1.5 hours, the data is corrupted (meaning one or more bytes get corrupted or missing). I have another board (which I did not make) where it runs fine for very long time. My question is, what can be the cause for this time-based corruption? The code I am sure is fine (very simple and as I said running fine on other board). From a hardware perspective it is just a micro (MSP430F169) connected to a MAX3232 and then to a PC.
>
> Thanks for your views on this
>

In a board I have, there is a UART that is used to send data to a PC. When connected and running, sending data every few seconds, after about 1-1.5 hours, the data is corrupted (meaning one or more bytes get corrupted or missing). I have another board (which I did not make) where it runs fine for very long time. My question is, what can be the cause for this time-based corruption? The code I am sure is fine (very simple and as I said running fine on other board). From a hardware perspective it is just a micro (MSP430F169) connected to a MAX3232 and then to a PC.

Thanks for your views on this