Forums

Re: LPC2000 UART drops characters silently?

Started by Leon Heller July 19, 2006
----- Original Message -----
From: "jayasooriah"
To:
Sent: Thursday, July 20, 2006 8:59 AM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
> --- In l..., "Leon Heller" wrote:
>
>> >
>> > As I reported, measured frequency is is 14.74 MHz using a 4-digit
>> > counter. Is this measurement not accurate enough?
>>
>> I'm not sure, you need to do the sums.
>> Please correct me if I am wrong -- my off-the-cuff calcuations:
>
> * Four decimal digit counter with 1 count error is 1 1000 or 0.1%
>
> * Half a bit error over 10 bit frame (1 start, 1 stop, 8-data) yields
> error of 1 in 20 or 5%.
>
> This is why I thought my measurement is accurate enough.
>
> Whatever the baud rate, signal is 16x oversampled and I expect the
> error rate not to be dependent on baud rate for this reason. You seem
> to suggest it may be but I don't believe you explain how. If I knew
> how it happens I could go looking for this cause ...

5% *is* borderline with 16x oversampling:

http://www.semiconductors.philips.com/acrobat_download/applicationnotes/AN10333_2.pdf

Try a better counter like my 8 digit one if you can find one and see what
you come up with. It would be interesting to see what difference those 15 pF
capacitors make to the crystal frequency.

Leon

An Engineer's Guide to the LPC2100 Series

--- In l..., "Leon Heller" wrote:

> 5% *is* borderline with 16x oversampling:
>
>
http://www.semiconductors.philips.com/acrobat_download/applicationnotes/AN10333_2.pdf

> Try a better counter like my 8 digit one if you can find one and see
what
> you come up with. It would be interesting to see what difference
those 15 pF
> capacitors make to the crystal frequency.

Yes, I agree 5% is the limit, but with frequency being 0.1% accuate
(*and* with autobaduding anway I cannot see how this is the issue.

The application note you refer to confirms what I knew in the ball
park regarding UART tolerance:



Any device with date code of 0443 or later should have the 4.4 % and
+5.6 % baud rate tolerance (one start bit, 8 data bits, no parity, and
one stop bit), and therefore, is immune to the variation between the
transmitter and the receiver clocks up to the specified tolerances



If the LPC UART does not meet this kind of specifications, then I
would consider, I would consider its design unusual to say the least.

Having said this, of the other issue is that it detects error in the
second stop bit, but discards the character silently. That clearly
points to an inssue in the UART and I would not be surprised if that
is the dominant mode of failure, not tolerances we are discussing here.

>
> Leon
>

Jaya





----- Original Message -----
From: "jayasooriah"
To:
Sent: Thursday, July 20, 2006 9:48 AM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
--- In l..., "Leon Heller" wrote:

> 5% *is* borderline with 16x oversampling:
http://www.semiconductors.philips.com/acrobat_download/applicationnotes/AN10333_2.pdf

> Try a better counter like my 8 digit one if you can find one and see
what
> you come up with. It would be interesting to see what difference
those 15 pF
> capacitors make to the crystal frequency.

Yes, I agree 5% is the limit, but with frequency being 0.1% accuate
(*and* with autobaduding anway I cannot see how this is the issue.

The application note you refer to confirms what I knew in the ball
park regarding UART tolerance:



Any device with date code of 0443 or later should have the -4.4 % and
+5.6 % baud rate tolerance (one start bit, 8 data bits, no parity, and
one stop bit), and therefore, is immune to the variation between the
transmitter and the receiver clocks up to the specified tolerances



If the LPC UART does not meet this kind of specifications, then I
would consider, I would consider its design unusual to say the least.

Having said this, of the other issue is that it detects error in the
second stop bit, but discards the character silently. That clearly
points to an inssue in the UART and I would not be surprised if that
is the dominant mode of failure, not tolerances we are discussing here.

I thought for a while just now that I had reproduced your problem! I was
getting *lots* of dropped characters at 300 baud, but I'd forgotten to
disable the UART interrupt after trying receive interrupts and then going
back to polled mode. 8-)

Leon

To be fair Jaya I'm more than happy to recognise one if I can actually
reproduce it!

I've had a fair crack now at trying to 'break' the uart on a couple of
different LPC parts without success. The only errors I could generate were
down to misconfigured stop bits - ie where one end is using 1 and the other
expecting 2 which is as expected.
As to scope accuracies, a half decent scope should be more than capable of
giving you sufficiently precise readings. I'm not conversant with the model
you listed to be honest but I imagine it should be fine - the harder part is
setting up the trigger.

Today I took the further step of deliberately trying to mismatch the
physical clock speeds at each end but once again it works within a 4%
tollerance for me.

If someone can post up a way for us to test these parts to induce this
erroneous behavior I'll be more than happy to try and verify it on my parts.
Until then though I can't see any issue here to be honest as we use the
UARTS on these parts extensively at a variety of baud rates with to date no
problems.

Andy
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
jayasooriah
Sent: 20 July 2006 04:53
To: l...
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
--- In l..., Robert Adsett wrote:

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

From the above and a previous comment by Robert, it sounds like only
Roert and I are prepared to recognise an "anomaly" in the UART design
in relation to stop bit handling. Sigh!

Jaya



----- Original Message -----
From: "Andrew Berney"
To:
Sent: Thursday, July 20, 2006 11:00 AM
Subject: RE: [lpc2000] Re: LPC2000 UART drops characters silently?
> To be fair Jaya I'm more than happy to recognise one if I can actually
> reproduce it!
>
> I've had a fair crack now at trying to 'break' the uart on a couple of
> different LPC parts without success. The only errors I could generate were
> down to misconfigured stop bits - ie where one end is using 1 and the
> other
> expecting 2 which is as expected.
> As to scope accuracies, a half decent scope should be more than capable of
> giving you sufficiently precise readings. I'm not conversant with the
> model
> you listed to be honest but I imagine it should be fine - the harder part
> is
> setting up the trigger.

As I think I have said, sending 'U' continuously (one stop bit) gives
alternating 1s and 0s which makes the check very easy.

Leon

--- In l..., "Andrew Berney" wrote:

> I've had a fair crack now at trying to 'break' the uart on a couple of
> different LPC parts without success. The only errors I could
generate were
> down to misconfigured stop bits - ie where one end is using 1 and
the other
> expecting 2 which is as expected.

Could I ask what you mean by errors? Are you getting error bits set
in LSR or just missing characters?

Jaya

--- In l..., "Andrew Berney" wrote:
>
> To be fair Jaya I'm more than happy to recognise one if I can
actually
> reproduce it!
>
> I've had a fair crack now at trying to 'break' the uart on a couple
of
> different LPC parts without success. The only errors I could
generate were
> down to misconfigured stop bits - ie where one end is using 1 and
the other
> expecting 2 which is as expected.
> As to scope accuracies, a half decent scope should be more than
capable of
> giving you sufficiently precise readings. I'm not conversant with
the model
> you listed to be honest but I imagine it should be fine - the
harder part is
> setting up the trigger.
>
> Today I took the further step of deliberately trying to mismatch the
> physical clock speeds at each end but once again it works within a
4%
> tollerance for me.
>
> If someone can post up a way for us to test these parts to induce
this
> erroneous behavior I'll be more than happy to try and verify it on
my parts.
> Until then though I can't see any issue here to be honest as we use
the
> UARTS on these parts extensively at a variety of baud rates with to
date no
> problems.
>
> Andy

My position is exactly the same: if there is some test I can run to
show a problem at low bit rates, I'm perfectly willing to try it out
to see if there is an issue with the parts.

My test results are exactly the same as Andy's: no errors at low (or
indeed high) bit rates, unless the number of stop bits on the UARTs
on the line do not match, in which case I see errors at all bit rates.

To summarize:

On the one hand we have one person seeing problems at low bit rates
on their system, claiming the root cause of the problem is a defect
in the processor's UART.

On the other, we have a lot of people who've done a lot of tests
using that processor (various members of the same family) who cannot
reproduce the problem.

Conclusion?

My own conclusion is that the problem is most likely in the first
person's system. This is not definitive: it could be down to an issue
with a very specific varient of the device, or at a very specific
crystal frequency. However, on the balance of probabilities my view
is that the issue being observed at low bit rates is specific to the
particular test environment being used.

My recommendation is to do more testing, until the critical
difference between the two types of system can be established. As
I've already said, I'm willing to partake in this testing, time and
target system availability permitting.

Brendan.

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "Andrew Berney" wrote:
>
> > I've had a fair crack now at trying to 'break' the uart on a
couple of
> > different LPC parts without success. The only errors I could
> generate were
> > down to misconfigured stop bits - ie where one end is using 1 and
> the other
> > expecting 2 which is as expected.
>
> Could I ask what you mean by errors? Are you getting error bits set
> in LSR or just missing characters?
>
> Jaya
>

Maybe you're ignoring my posts, but I've already given very
comprehensive test results if you're interested in the answer to this
question.

I've seen both types of errors, but **only** when the stop bit
configuration did't match (i.e. LPC21xx was configured with two and
the PC with one).

Brendan

--- In l..., "Andrew Berney" wrote:

> Today I took the further step of deliberately trying to mismatch
> the physical clock speeds at each end but once again it works
> within a 4% tollerance for me.

Thanks to your suggestion Andrew, I tried this experiment, but with
the system still "misconfigured" with host sending one stop bit, and
LPC expecting two stop bits.

I did this by auto-bauding at 300 baud. As per the original
experiment, if I cut and past 10 character line, I miss all but the
last character.

Now without auto-bauding again, I changed the host baud rate to 299
baud. Now I got framing errors reported!

I then changed the baud rate to 301, and again I got framing errors
reported!

Now I changed it back to 300 baud. Now LPC silently drops the
characters without any error bit set in LPC!

My conclusion:

a) there is an issue in the UART that causes characters to be silently
dropped; and

b) this phenomenon extremely sensitive to baud rate match between
testing device and LPC.

Over to the skeptics. I am off this thread for the moment as I have
other work to do. Will maintain a listening watch and respond any
further interesting ideas

Thanks again Andrew.

Regards.

Jaya

PS: Without an accurate match between the source and LPC target
crystals you are not going to catch the total dropout without error
phenomenon that I am able to deterministically reproduce on my board.

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "Andrew Berney" wrote:
>
> > Today I took the further step of deliberately trying to mismatch
> > the physical clock speeds at each end but once again it works
> > within a 4% tollerance for me.
>
> Thanks to your suggestion Andrew, I tried this experiment, but with
> the system still "misconfigured" with host sending one stop bit, and
> LPC expecting two stop bits.
>

As I suspected: the errors you see are where the system is
misconfigured.

Jaya, you have pointedly refused to respond to any of my recent
posts. Here's a simple question:

- Have you seen any errors where the line has been configured
correctly (i.e. both UARTs configured with the same number of stop
bits) and the bit timing has been directly measured as being within
tolerence (i.e. within 5% or so of the true value)?

If the answer is "yes", can we have your explanation of why nobody
else can reproduce this problem?

If the answer is "no", can you please, please stop wasting everyone's
time by making false claims (i.e. that there's a problem with low bit
rates).

If you fail to respond, the only logical conclusion to draw is that
any problem is only manifest when the UART has been incorrectly
configured or the clocks are signifcantly out, as this is what
everyone else's testing has revealed.

Brendan.