Re: LPC2000 UART drops characters silently?

Started by Leon Heller July 19, 2006
----- Original Message -----
From: "ian.scanlon"
To:
Sent: Wednesday, July 19, 2006 9:08 PM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
--- In l..., "ian.scanlon"
wrote:
>
> --- In l..., "brendanmurphy37"
> wrote:
> >
> > --- In l..., "jsm09a" > > yahoo.e35f5f@> wrote:
> >
> > > My compliments on your patience ;) One aspect that I haven't
seen
> > > addressed is possible dependence on differences in realized
baud
> > rates.
> > >
> > > In these tests, the source and destination will be sync'd to
> > different
> > > system clocks which may differ by an appreciable margin. I
> wonder
> > if
> > > the conflicting results could be explained by differences in
> system
> > > clock rates.
> > >
> > > Given that there appears to be a problem with the LPC2XXX when
it
> > is
> > > expecting two stop bits and receives only one, I wonder if a
> > similar
> > > problem might occur if the LPC2XXX was actually running at 275
> baud
> > > while the sender was running at a full 300 baud (resulting in a
> > > "shorter" stop bit than expected).
> > >
> > > Just a thought. Best regards, Scott.
> > >
> >
> > You're right of course - if the two clocks are out by an
> appreciable
> > amount, there is the possibility of timing errors.
> >
> > In a lot of cases, one or other (or both) sides are in fact out,
> > particularly if an even base clock rate like 10 Mhz or so is used
> > and the UART can only work of integer divisions of the base clock
> > (i.e. not all rates will divide evenly, and the nearest integer
> > value can be maybe 1 or 2% out).
> >
> > Asynchronous communication is designed to be tolerant of these
> > differences: the clocks are effectively re-synched on each byte
> > sent/received (usually on the falling edge of the start bit if my
> > memory serves). Therefore the timing errors can only accumulate
> over
> > the length of one byte (say 10 bits or so). It's a fairly
> > straightforward calculation to show how much they can deviate
> before
> > problems are likely to start occurring. It is a significant
amount
> > though: from memory the figure is somewhere around 5% or so (I
> could
> > be way off on this figure). In other words, so long as your UART
> > clock is within 5% of the true value, you should be OK.
> >
> > Brendan
> > Hi Brendan,
>
> I think you are correct in your baud rate tolerance ~5%. I recall
(on
> some micros) the bit stream is over sampled and then examined at a
> intermediate position within the following bits. I recall a
Motorola
> app note on this, I will poke around for it.
>
> I appreciate the time you took to investigate this, not sure why
> there is still dispute with your finding when there is no other
data.
>
> Regards,
> Ian
> (fellow Usual Suspect)
>
This describes the sampling technique and is clear that the UARTs are
designed to tolerate variation in clock rates.

>From Philips App note AN10333:

-Quote-
One method most UARTs now employ to allow larger frequency deviation
of the baud rates is to over-sample the incoming data at 16 times the
baud rate to determine the near center of the start bit. Once this is
done, the next bit is sampled 16 clocks later. At 16over-sampling
of the incoming data, the UART typically allows about 5 % of
deviation (assume a byte consists of one start bit, 8 data bits, and
one stop bit) from its programmed baud rate value without causing any
receiving error due to the baud rate differentiation between the two
UARTs.
-End Quote-

AN10333: SC16CXXXB baud rate deviation tolerance,Rev. 02 - 6 December
2004
If someone would be kind enough to send Jaya some instructions for
using an oscilloscope, maybe Jaya could test his own timing, forward
the measurements, and we can see if it fits within the +/-5% range.

A 'scope isn't much use for this sort of measurement (unless it is something
very expensive like a LeCroy), a frequency counter is better. The actual bit
timings could be tested by sending 'U' continuously - alternating 1s and 0s.

Leon

An Engineer's Guide to the LPC2100 Series

--- In l..., "Leon Heller" wrote:
>
> ----- Original Message -----
> From: "ian.scanlon"
> To:
> Sent: Wednesday, July 19, 2006 9:08 PM
> Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
>
>
> --- In l..., "ian.scanlon"
> wrote:
> >
> > --- In l..., "brendanmurphy37"
> > wrote:
> > >
> > > --- In l..., "jsm09a" > > > yahoo.e35f5f@> wrote:
> > >
> > > > My compliments on your patience ;) One aspect that I haven't
> seen
> > > > addressed is possible dependence on differences in realized
> baud
> > > rates.
> > > >
> > > > In these tests, the source and destination will be sync'd to
> > > different
> > > > system clocks which may differ by an appreciable margin. I
> > wonder
> > > if
> > > > the conflicting results could be explained by differences in
> > system
> > > > clock rates.
> > > >
> > > > Given that there appears to be a problem with the LPC2XXX when
> it
> > > is
> > > > expecting two stop bits and receives only one, I wonder if a
> > > similar
> > > > problem might occur if the LPC2XXX was actually running at 275
> > baud
> > > > while the sender was running at a full 300 baud (resulting in
a
> > > > "shorter" stop bit than expected).
> > > >
> > > > Just a thought. Best regards, Scott.
> > > >
> > >
> > > You're right of course - if the two clocks are out by an
> > appreciable
> > > amount, there is the possibility of timing errors.
> > >
> > > In a lot of cases, one or other (or both) sides are in fact out,
> > > particularly if an even base clock rate like 10 Mhz or so is
used
> > > and the UART can only work of integer divisions of the base
clock
> > > (i.e. not all rates will divide evenly, and the nearest integer
> > > value can be maybe 1 or 2% out).
> > >
> > > Asynchronous communication is designed to be tolerant of these
> > > differences: the clocks are effectively re-synched on each byte
> > > sent/received (usually on the falling edge of the start bit if
my
> > > memory serves). Therefore the timing errors can only accumulate
> > over
> > > the length of one byte (say 10 bits or so). It's a fairly
> > > straightforward calculation to show how much they can deviate
> > before
> > > problems are likely to start occurring. It is a significant
> amount
> > > though: from memory the figure is somewhere around 5% or so (I
> > could
> > > be way off on this figure). In other words, so long as your UART
> > > clock is within 5% of the true value, you should be OK.
> > >
> > > Brendan
> > >
> >
> > Hi Brendan,
> >
> > I think you are correct in your baud rate tolerance ~5%. I recall
> (on
> > some micros) the bit stream is over sampled and then examined at a
> > intermediate position within the following bits. I recall a
> Motorola
> > app note on this, I will poke around for it.
> >
> > I appreciate the time you took to investigate this, not sure why
> > there is still dispute with your finding when there is no other
> data.
> >
> > Regards,
> > Ian
> > (fellow Usual Suspect)
> >
> This describes the sampling technique and is clear that the UARTs
are
> designed to tolerate variation in clock rates.
>
> From Philips App note AN10333:
>
> -Quote-
> One method most UARTs now employ to allow larger frequency deviation
> of the baud rates is to over-sample the incoming data at 16 times
the
> baud rate to determine the near center of the start bit. Once this
is
> done, the next bit is sampled 16 clocks later. At 16over-sampling
> of the incoming data, the UART typically allows about 5 % of
> deviation (assume a byte consists of one start bit, 8 data bits, and
> one stop bit) from its programmed baud rate value without causing
any
> receiving error due to the baud rate differentiation between the two
> UARTs.
> -End Quote-
>
> AN10333: SC16CXXXB baud rate deviation tolerance,Rev. 02 - 6
December
> 2004
>
>
> If someone would be kind enough to send Jaya some instructions for
> using an oscilloscope, maybe Jaya could test his own timing, forward
> the measurements, and we can see if it fits within the +/-5% range.
>
> A 'scope isn't much use for this sort of measurement (unless it is
something
> very expensive like a LeCroy), a frequency counter is better. The
actual bit
> timings could be tested by sending 'U' continuously - alternating
1s and 0s.
>
> Leon
>

This may be a matter of debugging style. It is the bit time that
needs to be measured and if that can be measured directly there is
less room for error. I think measuring the frequency of repeating
pattern ('U') may be unreliable if you have start/stop bits. Pulse
width measurement should be fairly accurate even on an old analogue
scope. Anyway, a mater of style I guess.

Ian





Heres my 2 cents:

I saw all of the great explanations about how UARTS work with
16x clocks, wait for start bit, count 8 clocks and sample the line. One
fact has been omitted. Since a start bit and a stop bit are of the same
polarity, the UART will say it sees a start bit 8 clocks after it thinks it
began . Without a false-start bit (I mean a 1 bit or greater of the RX data
line being unasserted or idle line) the UART will continue to sample 8
clocks in from where it THINKS the start bit asserted and then sample the
line. If the clocks are not the same (and they never really can be unless
they are derived from a rock solid frequency standard) where it looks for
the center of the cell and where it really is will creep until the UART is
sampling at RX data transition time (BAD BAD BAD!). So sending continuous
back to back data will ALWAYS eventually fail. An idle period of at least
2 bit times occasionally will re-sync the receiving UART. How often you
need to do that depends on your worst case oscillator frequency
discrepancies.

Regards,

Mister RS-232

Bennett Scharf

Principal Electrical Engineer
Colorado Altitude Training
3125 Sterling Circle, Suite 105
Boulder, CO 80301

tel: +1 303.440.4102 x 116
fax: +1 303.440.4105
toll free: 1-877-ALTITUDE
www.altitudetraining.com



On Wed, Jul 19, 2006 at 04:01:03PM -0600, Bennett Scharf wrote:
> fact has been omitted. Since a start bit and a stop bit are of the same
> polarity, ...

Since when?

--
Clyde Stubbs, HI-TECH Software | Phone Fax
Email: c...@htsoft.com | USA: (408) 490 2885 (408) 490 2885
WWW: http://www.htsoft.com/ | AUS: +61 7 3722 7777 +61 7 3722 7778
---
HI-TECH C: compiling the real world.

I'm sorry. I mis-spoke, but if the UART does not re-sync on the next start
edge that will be a problem. One can never guarantee that unless you are
the chip designer. (Lord knows where they hide that guy!)

Bennett

_____

From: l... [mailto:l...] On Behalf Of
Clyde Stubbs
Sent: Wednesday, July 19, 2006 4:17 PM
To: l...
Subject: Re: [lpc2000] LPC2000 UART drops characters silently?

On Wed, Jul 19, 2006 at 04:01:03PM -0600, Bennett Scharf wrote:
> fact has been omitted. Since a start bit and a stop bit are of the same
> polarity, ...

Since when?

--
Clyde Stubbs, HI-TECH Software | Phone Fax
Email: clyde@htsoft. com | USA: (408) 490 2885
(408) 490 2885
WWW: http://www.htsoft. com/ | AUS: +61 7 3722 7777
+61 7 3722 7778
----------------------
HI-TECH C: compiling the real world.



Bennett Scharf wrote:
> Heres my 2 cents:
>
> I saw all of the great explanations about how UARTS work with
> 16x clocks, wait for start bit, count 8 clocks and sample the line. One
> fact has been omitted. Since a start bit and a stop bit are of the same
> polarity, the UART will say it sees a start bit 8 clocks after it thinks it
> began . Without a false-start bit (I mean a 1 bit or greater of the RX data
> line being unasserted or idle line) the UART will continue to sample 8
> clocks in from where it THINKS the start bit asserted and then sample the
> line. If the clocks are not the same (and they never really can be unless
> they are derived from a rock solid frequency standard) where it looks for
> the center of the cell and where it really is will creep until the UART is
> sampling at RX data transition time (BAD BAD BAD!). So sending continuous
> back to back data will ALWAYS eventually fail. An idle period of at least
> 2 bit times occasionally will re-sync the receiving UART. How often you
> need to do that depends on your worst case oscillator frequency
> discrepancies.

Sorry, you're not geting 2 cents from me :) Uarts don't think, they just
do (Yeah, I know, I use the word "think" as well). The sampling of 8
clocks you mentioned only ever applies when it is sampling for a start
bit after which the interval is 16 clocks from the center of the start
bit. The 16 times clock is a compromise for digital logic to get as
close to the center of the bit after the high-to-low transition of the
leading edge of the start bit (Remembering that the transition is
asynchronous to the sampling clock).

This is where the error does creep in a little in that the center of the
start bit is only as good as the resolution of the sampling clock. So if
the sampling of the center of the start bit is off by 0.9 of a sample
clock then the sampling of the data/stop bits will be off by that amount
plus any clock mismatch between the uarts.

ONCE the stop bit(s) has been sampled and the receive holding register
or FIFO loaded then the uart is ready again, admittedly this is probably
less than 8 sampling clocks.

Ooops, I see you have just posted a correction.

But a continuous asynch stream can become unreadable if the receiving
uart resets into the middle of a character. But most asynch streams do
have gaps thank goodness.

I have designed a lot of digital logic in the past and basic uarts
aren't that difficult.

*Peter*

----- Original Message -----
From: "jayasooriah"
To:
Sent: Thursday, July 20, 2006 1:32 AM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
> --- In l..., "Leon Heller" wrote:
>
>> > Given that there appears to be a problem with the LPC2XXX when it is
>> > expecting two stop bits and receives only one, I wonder if a similar
>> > problem might occur if the LPC2XXX was actually running at 275 baud
>> > while the sender was running at a full 300 baud (resulting in a
>> > "shorter" stop bit than expected).
>>
>> That is what I suspected, but Jaya is apparently unable to
>> measure his clock frequency. That's the first thing I'd have
>> checked.
>>
>> Leon
>
> Leon
>
> * I thought I responded to this. Measurements using Tektronix TMS220
> (10MHz 1GS/s) reads the clock frequency as 14.7 MHz.
>
> * Infinite persistence integration does not reveal clock jitter or
> drift in the eye diagrams.
>
> Caveat: my observation is limited to accuracy of TMS220.
>
> I am prepared to get a precision oven controlled frequency counter to
> see if there is something here I am missing, but would I be looking for?

That's the point I was making, a scope isn't accurate enough. You don't need
anything special for measuring the frequency accurately, I used a low-cost
counter made for amateur radio applications. Any decent electronics lab
should have something similar.

>
> Will this explain why UART designs detect but not report stop bit
> violation?

I'm not sure, but it's worth checking as it is so simple, and it's
fundamental to the UART timing.

Leon

At 03:39 AM 7/20/2006 +0100, Leon Heller wrote:

>That's the point I was making, a scope isn't accurate enough. You don't need
>anything special for measuring the frequency accurately, I used a low-cost
>counter made for amateur radio applications. Any decent electronics lab
>should have something similar.

Maybe I'm spoiled but I would expect a decent scope to get well within what
you need for a check. Go to 6 divisions per bit that gives a resolution on
an analog scope of 3% which would be marginal at best. But on the low
mid-range DSO I use I can do a couple of orders of magnitude better than
that. The trick on a cheaper DSO might be getting the triggering set
up. If you have sufficient memory depth it becomes very straightforward
and you don't need a $50000 scope to do it.

Oh, and you do need to check bit time not crystal frequency. The later
doesn't really tell you much except that your source is stable. Useful for
helping diagnose a problem once you know your bit widths are off but won't
tell you a thing about what they really are

Robert
http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock."

--- In l..., "Leon Heller" wrote:
>
> You don't need anything special for measuring the frequency
> accurately, I used a low-cost counter made for amateur radio
> applications. Any decent electronics lab should have something
> similar.

Sorry I misunderstood you as saying I needed crystal precision
counter. My 4-digit counter shows 14.74 and ocassionally 14.75 MHz.

> > Will this explain why UART designs detect but not report stop bit
> > violation?
>
> I'm not sure, but it's worth checking as it is so simple, and it's
> fundamental to the UART timing.

This is where I am trying to understand what you alude to as "counter
intuitive" phenomenon. Is this related to accuracy or stability of
the crystal?

On the board I see the caps there where the should be. I cannot read
the cap values but design document says 15pf on either ends of the
crystal.

I am inclined to rule out accuracy issues becuase given the whole idea
behind asynchronous communciation is to allow systems work reliabliy
when they do not have a common timebase reference.

Besides, as I said, in auto-bauding, host speed error will just result
in a different divisor count. [The divisor count for any baudrate is
exactly what I expect anyway.]

If it is a stability issue, for it to affect low baud rate and not
higher baudrate, it must be sufficiently long term stability problem
of the type that I would be able to pick up with a 4-digit counter or
on 100MHz CRO.

I can get to my lab and use a higher resolution counter to report a
six digit reading. Given the above, do you still think I should?

I believe the simpler explanation (my experiment coupled with what
others have reported as 'errors' or 'lockups' is that LPC UART
validates stop bit at end of bit, not in the middle of the bit as
other designs do, and hence is more prone to stop bit errors.

The fact that LPC detects the error (resulting in dropping the data)
but does not report it clearly points to an issue in the UART to be
looked into. I am not sure how "normal" is this behaviour as I have
not seen this in any other UARTs, discrete or embedded.

Regards,

Jaya

----- Original Message -----
From: "Robert Adsett"
To:
Sent: Thursday, July 20, 2006 4:07 AM
Subject: Re: [lpc2000] Re: LPC2000 UART drops characters silently?
> At 03:39 AM 7/20/2006 +0100, Leon Heller wrote:
>
>>That's the point I was making, a scope isn't accurate enough. You don't
>>need
>>anything special for measuring the frequency accurately, I used a low-cost
>>counter made for amateur radio applications. Any decent electronics lab
>>should have something similar.
>
> Maybe I'm spoiled but I would expect a decent scope to get well within
> what
> you need for a check. Go to 6 divisions per bit that gives a resolution
> on
> an analog scope of 3% which would be marginal at best. But on the low
> mid-range DSO I use I can do a couple of orders of magnitude better than
> that. The trick on a cheaper DSO might be getting the triggering set
> up. If you have sufficient memory depth it becomes very straightforward
> and you don't need a $50000 scope to do it.
>
> Oh, and you do need to check bit time not crystal frequency. The later
> doesn't really tell you much except that your source is stable. Useful
> for
> helping diagnose a problem once you know your bit widths are off but won't
> tell you a thing about what they really are

A decent scope should be able to measure the bit time quite accurately, as
you say, but calculating it from the measured clock frequency would be a lot
more accurate.

Leon