Forums

Re: LPC2000 UART drops characters silently?

Started by Leon Heller July 19, 2006
--- In l..., "brendanmurphy37"
wrote:

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

You are right Brendan, I have been ignoring your post. I am deeply
sorry, but it takes too much effort to explain things to you.

If you take some time to think about the implications of my most
findings, you may eventually appreciate that the LPC UART is sensitive
to baud rates, 300 baud as an example.

This problem in the UART that can bite anyone. It can bite you if
your baudrate is dead on, but not when your baud rate is off either
way by as little as 0.3 percent.

I don't like your hodge podge testing ... if you want to test, you
craft the test to validate a particular hypothesis, or alternatively
use professional equipment and do general testing by varying specific
parameters while observing the system.

Feeding one UART back to another UART on the same device (when the
device itself is the suspect) is a foolish thing to do. Please
forgive me for not commenting on results obtained by such methods.

Bye for now.

Jaya

An Engineer's Guide to the LPC2100 Series

--- In l..., "jayasooriah" wrote:
>
> --- In l..., "brendanmurphy37"
> wrote:
>
> > Jaya, you have pointedly refused to respond to any of my recent
> > posts. Here's a simple question:
>
> You are right Brendan, I have been ignoring your post. I am deeply
> sorry, but it takes too much effort to explain things to you.
>

How much effort does it take to answer a simple question?

See my last post for the question.

> If you take some time to think about the implications of my most
> findings, you may eventually appreciate that the LPC UART is
sensitive
> to baud rates, 300 baud as an example.
>
> This problem in the UART that can bite anyone. It can bite you if
> your baudrate is dead on, but not when your baud rate is off either
> way by as little as 0.3 percent.
>

As I said, and as my (and others) testing has confirmed, the UART
works with no problems when the stop bit configuration matches that
on the other end of the line, and the speed is within tolerance. This
is exactly what I'd expect.

You claim to have seen something different, yet can't explain why
nobody else can repeat your results.

> I don't like your hodge podge testing ... if you want to test, you
> craft the test to validate a particular hypothesis, or alternatively
> use professional equipment and do general testing by varying
specific
> parameters while observing the system.

Please stop insulting me and others.

I am very well aware of how to conduct a test.

>
> Feeding one UART back to another UART on the same device (when the
> device itself is the suspect) is a foolish thing to do. Please
> forgive me for not commenting on results obtained by such methods.
>

If you'd bother to read what I actually did, you'd realise that this
is not the test configuration I used.

I used the UART on the LPC2xxx talking through a MAX232 (or similar)
across a standard serial cable to the serial port on a PC.

If you want more details of my test environment, I'm happy to provide
them.

> Bye for now.
>

Yipee!

As you have failed to answer the question I posed, the only logical
conclusion to draw is that there is no problem at low bit rates where
the UART is correctly configured. That is what my, and others,
testing has revealed.

As I said, if you have information that contradicts this, you'll have
to explain why we cannot duplicate your results.

As I also said, please top wasting my time be reporting error
conditions that do not exist.

Brendan.

One more thing I forgot to mention. The same test at 9600 baud also
produces similar results: no errors reported at 9600 baud, but framing
errors reported at 9550 and 9650. Thats just 0.005 percent change.

I have updated this information in my limitations and workarounds page at:

http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html

As always, feel free to let me know of errors and/or missions.

Regards,

Jaya

--- In l..., "jayasooriah" wrote:

> 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

jayasooriah wrote:
> One more thing I forgot to mention. The same test at 9600 baud also
> produces similar results: no errors reported at 9600 baud, but framing
> errors reported at 9550 and 9650. Thats just 0.005 percent change.
>
> I have updated this information in my limitations and workarounds page at:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
>
> As always, feel free to let me know of errors and/or missions.

Ummm, just a quick back of the envelope calculation shows that you
have changed the baud rate by about 50 parts in 10,000 which is
equivalent to 0.5 parts in 100 which is 0.5%

Ralph
--- In l..., "jayasooriah" wrote:
>
> One more thing I forgot to mention. The same test at 9600 baud
also
> produces similar results: no errors reported at 9600 baud, but
framing
> errors reported at 9550 and 9650. Thats just 0.005 percent change.
>
> I have updated this information in my limitations and workarounds
page at:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
>

I thought you'd said you weren't going to post anything more on this?

> As always, feel free to let me know of errors and/or missions.
>
Since you ask, from what I've seen your main contention is not
correct, namely:

"When UART is polled and receive channel is saturated, incoming
characters are lost when operating at low but not high baud rates".

I'd replace it with the rather more accurate:

"When the UART is mis-configured, for example with two stop bits when
the configuration of the peer device is one stop bit, errors are
observed when data is sent with no gaps between them."

But that's hardly news is it?

Brendan.

--- In l..., "brendanmurphy37"
wrote:

> Since you ask, from what I've seen your main contention is not
> correct, namely:
>
> "When UART is polled and receive channel is saturated, incoming
> characters are lost when operating at low but not high baud rates".
>
> I'd replace it with the rather more accurate:
>
> "When the UART is mis-configured, for example with two stop bits when
> the configuration of the peer device is one stop bit, errors are
> observed when data is sent with no gaps between them."
>
> But that's hardly news is it?
>
> Brendan.

Stop being silly. Configuring LPC UART for two stop bits is not a
mis-configuration. Also, sending 8-bit 2-stop bit data with error in
the last stop bit is not mis-configuration either.

Obviously you do not understand paramatrised validation testing of
specific functions, in this case, to determine if the UART is able to
detect stop bit violation.

--- In l..., Ralph Hempel wrote:

> Ummm, just a quick back of the envelope calculation shows that you
> have changed the baud rate by about 50 parts in 10,000 which is
> equivalent to 0.5 parts in 100 which is 0.5%
>
> Ralph
>

Thanks Ralph for pointing out error on poster -- I was flipping
between using percentage and ratio. You will be pleased to note that
in my write up, I said it as 0.5 percent.

--- In l..., "jayasooriah" wrote:

> Stop being silly. Configuring LPC UART for two stop bits is not a
> mis-configuration. Also, sending 8-bit 2-stop bit data with error
in
> the last stop bit is not mis-configuration either.
>

It is a mis-configuration if the peer device is configured to
something else.

All you've proved is that errors are encountered when the bit stream
received doesn't match the configuration of the UART. As I said, this
is hardly news, is it?

> Obviously you do not understand paramatrised validation testing of
> specific functions, in this case, to determine if the UART is able
to
> detect stop bit violation.
>

Agsin, I'd ask you to stop the insults.

How does the UART's response to stop bit violations relate to your
main contention that the UART drops characters at low bit rates?

It may or may not drop characters when there's an error in the bit
sream. I have seen this behaviour myself. I've also seen it get the
data wrong in those circumstances, as well as reporting framing
errors.

I have never seen, nor has anyone else from what I can gather, any
evidence of it dropping characters when receiving a valid bit stream
at low bit rates, which is what you originally claimed.

Hance my suggestion to change the working of your main contention: at
best it is extremnely misleading.

Now I really have spent way more time on this than it deserves; I've
nothing more to say on the topic.

Brendan.

--- In l..., "jayasooriah" wrote:
>
> Stop being silly. Configuring LPC UART for two stop bits is not a
> mis-configuration. Also, sending 8-bit 2-stop bit data with error in
> the last stop bit is not mis-configuration either.
>
> Obviously you do not understand paramatrised validation testing of
> specific functions, in this case, to determine if the UART is able to
> detect stop bit violation.
>

OK, then the exact statement should be:
"When the UART is configured for 8-N-2, and it receives a character
with the second stop bit = 0, it drops the character without
signalling a frame error"

from the tests performed by all people in the group I'll add also
"This occurs at any baud rate".

I'll add also (but I'm not so sure, anyone tested this?):
"This occurs handling the uart in polled mode or in interrupt mode"

jayasooriah wrote:



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

OK, everyone take a deep breath and step back from the problem for
just a minute.......

For the sake of argument, let's assume that Jaya is correct, and
that there may be a problem with the UART. There are only a few things
that can be done about it:

1. Ask Philips to change the design of the UART. I seriously doubt this
would ever happen.

2. Move to a different part that has a UART that tolerates the test
setup. More likely to happen, and might be a relief.

3. Be a good engineer and think about the problem some more.

Now, for the sake of argument, what is the difference between a UART
occasionally dropping a character and real noise or a break in the
communication line?

I don't want to get into discussions about how many characters are lost
at what baud rates, or how mismatched configurations are supposed to
be fine.

Assuming that the UART is going to find all the errors for you is not
good enough in _any_ communication scheme.

The root question is, how do you detect and handle dropped characters in
a message, regardless of why they were dropped. The application must be
made more tolerant.

I do not advocate software workarounds for bad electrical designs. This
is the same as handling the possibility of real-world data corruption
and there are many good books on protocol design that can help you
through the problem.

Cheers, Ralph