Re: LPC2000 UART drops characters silently?

Started by Leon Heller July 19, 2006
----- Original Message -----
From: "jsm09a"
To:
Sent: Wednesday, July 19, 2006 6:43 PM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
> --- In l..., "brendanmurphy37"
> wrote:
>
>> I've no doubt the results of your testing are valid. However, nobody
>> has been able to reproduce your "but drops characters at 19200 baud
>> and below" failure mode.
>
> Brendan,
>
> 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).

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

An Engineer's Guide to the LPC2100 Series

--- In l..., "Leon Heller" wrote:
>
> That is what I suspected, but Jaya is apparently unable to measure
his clock
> frequency. That's the first thing I'd have checked.
>

Same here, which is why I asked the question (a long time ago now) on
whether what was actually being sent matched with what is thought to
be sent. This can only really be confirmed by placing something on the
line (a simple scope will do). Has this been donein Jaya's tests? I
don't know.

As I mentioned, I confirmed in my own testing that what was being sent
in my setup was correct (at least to a reasonable tolerance).

Brendan.

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

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

Here is the orignial problem scenario and how it developed:

1/ Characters were lost during integration testing, with no evidence
of this at the UART level, only at the record level check sums.

2/ Further functional testing at the driver level failed to reproduce
the problem.

2/ On an independent system, with same hardware configuration (FTDI
FT233 directly to UART), I could simulate the problem with my boot loader.

4/ Rather than report on what happens inside my boot loader, I chose
to repeat the test with the Philips Boot Loader and observed the same
thing: it drop characters at low baud rates.

[As the Philips Boot Loader has a deficient CR NL translation regime,
this is not conclusive enough although it is clear from the transcript
that what is happening is more than just the CR NL translation error.]

3/ I designed a simple deterministic experiment to demonstrated what
I found: UART detects but does not report stop bit violations.

4/ Based on the this observation (by preventing stop bit violations)
the original problem was solved. That it is now fixed is a good
indication that my diagnosis is most likely correct.

In so as far as the original problem report is concerned, even if one
is skeptical of my diagnosis, the fact that the problem was solved by
extending stop bit timing cannot be dismissed without justification.

There are those who want keep agruing and running tests that do not
apear to bear any relevance to the problem and its diagnosis.

In the world of scientific reasoning, it does not matter how many
claim that they cannot repeat the problem, if it is possible to find
just one method to deterministicaly demonstrate the problem.

I am now somewhat curious. Is there no one out there who is driving
the UART using FTDI chips directly? What other USB based UARTs do
people use? Is the hardware combination (FT232BM chip with LPC2292)
the culprit cause?

Thanks

Jaya

Apologies: it should have been Tektronix TDS220, not TMS220.

--- In l..., "jayasooriah" wrote:
>
> --- 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?
>
> Will this explain why UART designs detect but not report stop bit
> violation?
>
> Here is the orignial problem scenario and how it developed:
>
> 1/ Characters were lost during integration testing, with no evidence
> of this at the UART level, only at the record level check sums.
>
> 2/ Further functional testing at the driver level failed to reproduce
> the problem.
>
> 2/ On an independent system, with same hardware configuration (FTDI
> FT233 directly to UART), I could simulate the problem with my boot
loader.
>
> 4/ Rather than report on what happens inside my boot loader, I chose
> to repeat the test with the Philips Boot Loader and observed the same
> thing: it drop characters at low baud rates.
>
> [As the Philips Boot Loader has a deficient CR NL translation regime,
> this is not conclusive enough although it is clear from the transcript
> that what is happening is more than just the CR NL translation error.]
>
> 3/ I designed a simple deterministic experiment to demonstrated what
> I found: UART detects but does not report stop bit violations.
>
> 4/ Based on the this observation (by preventing stop bit violations)
> the original problem was solved. That it is now fixed is a good
> indication that my diagnosis is most likely correct.
>
> In so as far as the original problem report is concerned, even if one
> is skeptical of my diagnosis, the fact that the problem was solved by
> extending stop bit timing cannot be dismissed without justification.
>
> There are those who want keep agruing and running tests that do not
> apear to bear any relevance to the problem and its diagnosis.
>
> In the world of scientific reasoning, it does not matter how many
> claim that they cannot repeat the problem, if it is possible to find
> just one method to deterministicaly demonstrate the problem.
>
> I am now somewhat curious. Is there no one out there who is driving
> the UART using FTDI chips directly? What other USB based UARTs do
> people use? Is the hardware combination (FT232BM chip with LPC2292)
> the culprit cause?
>
> Thanks
>
> Jaya
>