Reply by jayasooriah July 27, 20062006-07-27
--- In l..., "reallygene" wrote:
> A careful reading of the UART errata reveals that polling the UART by
> repeatedly reading registers such as LSR >WILL< result in a bus
> contention that causes status bits to not be registered.

For what it is worth, here is what I think is the problem is:

1/ As you point out, the errata alludes us to the fact that there is
a sync problem with UART status registers (I am inclined to think this
is a generic problem with the bus given other peripherals like the
TIMER also suffer from the same problem).

2/ In the same way FE and other error bits can be lost if the LSR is
read while the particular bit is being set, it is also possible to
lose DR bit, and also the character for which the DR bit was being set.

3/ While this problem was observed in both interrupt driven systems
(hard to make it repeatable) and in polled experiments, whether or not
one hits the problem depends on a number of parameters, including baud
rates in use and, crystal frquencies.

4/ The specific baud rate sync issue (results are different at 299
and 301 baud compared to 300 baud) may well be yet another
manifestation of the same contention problem.

Finally I urge my critics to note that I am able to demonstrate the
missing character problem using the Boot Loader itself on my LPC2292.
You cannot do better than that in terms of alluding Philips to the
problem.

[Leon, I have since checked my crystal and over 1 second it counts
exactly 14745600 counts, and for the FM232MB crystal, it counts
exactly 6000000 counts.]

So it is quite possible that one does see manifestations of this
problem unless one hits combinations like what I hit, and this may the
reason why Philips chose not to document this problem on the basis
that it is not relevant from a probability perspective.

No doubt it will be addressed in future silicon releases but with the
current shortage, I suspect a number of people will have to live with
silicon versions with such bugs for some time.

Jaya

An Engineer's Guide to the LPC2100 Series

Reply by jayasooriah July 27, 20062006-07-27
--- In l..., "reallygene" wrote:

> You will NEVER see the supposed framing error if you poll, rather
> than using the interrupt mechanism.

You are suggesting LPC UARTs will not set FE bit at all if one is
polling. This means applications like boot loaders will never see
framing errors.

Well my boot loader does. Does that count?

> Even with interrupts, care must
> be taken to avoid reading the registers more than once in the
> context of the interrupt.
>
> Frankly, anyone using these parts and NOT using the interrupt
> capabilities provided is an amateur.

Thank Gene. I always thought one who does not know to use the UARTs
in both polled and interrupt modes is not a likely to be a professional.

The core question I raised is that characters were seen dropped, and I
crafted an experiment to demonstrate this. Anyone can pick up the hex
file and run it on their system to validate the experiment.

More specifically the sensitivity of the experiment -- different set
of repeatable results for both 299 and 301 baud, compared to 300 baud
does IMO indicate that kind of problems one expects to see on LPC UART
design is not something that you easily demonstrate.

Have you tried the experiment? Do you see missing characters? If you
do, are you able to explain why they are missing?

Regards,

Jaya
Reply by brendanmurphy37 July 26, 20062006-07-26
--- In l..., "reallygene" wrote:
>
> --- In l..., "George M. Gallant, Jr."
> wrote:
> >
> > Frankly, anyone making such an absurd statement is an IDIOT!
> >
> > George
> >
> >
> > Nice addressing of the real issue there, George.
>
> A careful reading of the UART errata reveals that polling the UART
by
> repeatedly reading registers such as LSR >WILL< result in a bus
> contention that causes status bits to not be registered.
>
> The advantage of using the UART interrupt is that, provided the
FIFO
> is enabled, and the service routine is not too long, the interrupt
> context is the safest time to read the status bits (character has
> already arrived, and any errors have been registered).
>
> Any LPC21xx or LPC22xx that has the UART module has this flaw.
>
> Most respondents to the OP use the UART interrupts and report not
> encountering a problem; the OP uses polling, and encounters a
problem
> specifically identified by the errata (framing errors not
recorded),
> and insists it is a hardware problem (which it is, just not the
one
> the OP believes).
>
> --Gene
>

At the risk of re-opening this, the original claim (which is still
being made as far as I understand) was that data was being lost at
low bit rates. I also believe that nobody was able to replicate this
behaviour, unless framing errors were deliberatley introduced, when
dropped data was one of three failure modes observed (the others
being incorrect data and correctly detected framing errors). Whether
this is as a result of the documented h/w problem or not is kind of
a moot point.

The bottom line (unless someone can put forward a test to prove
otherwise) is:

- there's no evidence the parts drop correctly framed data at low
bit rates (or indeed at any speed)

- polled receive works just fine in the absense of errors on the
line (it's only the error bits that are affected by the documented
fault)

- if there are errors on the line, not all are detected by a polled
driver

It would be interesting to know (in an acedemic sense) if a regular
interrupt driven (and correctly written) driver correctly detects
all error conditions. As I pointed out in an earlier post, most UART
drivers will silently ignore any such errors in any case.

By the way, of course UART drivers are invariably interrupt driven
in real system. However, it is not idiotic to use a polled driver
for specific purposes, e.g. when interrupts are switched off
deliberately for some other reason, or as in this case to test a
particular behaviour.

My own persistance in pursuing the discussion (at annoyance to many
I'm sure, and for which I apologise) was to see if there was any
evidence for the original claim (data dropped at low bit rates),
which would indeed be a new (and very worrying) error condition.

When it was clear there was none, I gave up.

Brendan.

P.S. I promise (again!) not to post anything else on this topic....
Reply by reallygene July 26, 20062006-07-26
--- In l..., "George M. Gallant, Jr."
wrote:
>
> Frankly, anyone making such an absurd statement is an IDIOT!
>
> George
>
>
>

Nice addressing of the real issue there, George.

A careful reading of the UART errata reveals that polling the UART by
repeatedly reading registers such as LSR >WILL< result in a bus
contention that causes status bits to not be registered.

The advantage of using the UART interrupt is that, provided the FIFO
is enabled, and the service routine is not too long, the interrupt
context is the safest time to read the status bits (character has
already arrived, and any errors have been registered).

Any LPC21xx or LPC22xx that has the UART module has this flaw.

Most respondents to the OP use the UART interrupts and report not
encountering a problem; the OP uses polling, and encounters a problem
specifically identified by the errata (framing errors not recorded),
and insists it is a hardware problem (which it is, just not the one
the OP believes).

--Gene
Reply by brendanmurphy37 July 26, 20062006-07-26
--- In l..., "George M. Gallant, Jr."
wrote:
>
> Frankly, anyone making such an absurd statement is an IDIOT!
>
> George
>
> >
> > --Gene
> > On Wed, 2006-07-26 at 15:13 +0000, reallygene wrote:
> > Frankly, anyone using these parts and NOT using the interrupt
> > capabilities provided is an amateur.
> >
> > --Gene
> >
>
>

Guys,

Can you stop the abuse, please?

The original thread was bad enough without throwing in a pair of
insults as addenda.

I'd strongly urge everyone else not to say anything more on the
topic: those interested can read the many points made (most many
times over) in the original thread.

Brendan.
Reply by "George M. Gallant, Jr." July 26, 20062006-07-26
Frankly, anyone making such an absurd statement is an IDIOT!

George

>
> --Gene
> On Wed, 2006-07-26 at 15:13 +0000, reallygene wrote:
> Frankly, anyone using these parts and NOT using the interrupt
> capabilities provided is an amateur.
>
> --Gene
>
Reply by reallygene July 26, 20062006-07-26
--- 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.
>
> 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
I simply can not believe the length of this thread.

Doesn't anyone read the errata published for these parts? As
written, polling practically any status register is certain to
eventually clear a condition as the hardware is attempting to set it.
You will NEVER see the supposed framing error if you poll, rather
than using the interrupt mechanism. Even with interrupts, care must
be taken to avoid reading the registers more than once in the context
of the interrupt.

Frankly, anyone using these parts and NOT using the interrupt
capabilities provided is an amateur.

--Gene

"UART.1 Coinciding VPB read and hardware register update.

Introduction:Reading the contents of the IIR,LSR and MSR registers
will clear certain bits in the register.

1. Reading the IIR should clear the THRE status if THRE is the
highest priority pending interrupt (Only affects UART1).

2. Reading LSR should clear the OE/PE/FE/BI bits (affects both UART0
and UART1).

3. Reading MSR should clear the Delta DCD/Trailing Edge RI/Delta
DSR/Delta CTS bits (Only affects UART1).

Problem:If hardware is setting one of these above bits while the
software is reading the contents of the register the reading process
clears all bits in the register including the bit that got set by
hardware.

2006 June 16 7
Philips Semiconductors
LPC2138 Erratasheet
The software reads the old value though and the bit that got set by
hardware is lost."

Read the rest at:
http://www.semiconductors.philips.com/pip/LPC2132FBD64.html
Reply by Robert Adsett July 20, 20062006-07-20
Quoting jayasooriah :

> --- In l..., "Leon Heller" wrote:
>
>> I'm not sure what error those 15 pF capacitors would give, I could
> simulate
>> the oscillator and see what I get, but it's easier to measure the
> frequency.
>> I've got the correct value capacitors on my boards and the frequency
> is very
>> close to nominal.
>>
>> Leon
>
> As I reported, measured frequency is is 14.74 MHz using a 4-digit
> counter. Is this measurement not accurate enough?

What's the measured (not calculated) bit time? The crystal frequency
is several
steps removed from the bit time.

Robert

Reply by Jerzy Lelusz July 20, 20062006-07-20
Bennett Scharf wrote:

Depends on the UART design. What is it doing after sampling centre of
the stop bit?
Is it waiting next 8xCLK, or is it trying to resync immediately after
centre of stop bit?
I _think_ it's not waiting for the end of the stop bit.... but I can be
wrong...

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

--
Jerzy Lelusz
Senior Electronics Engineer
Geola Technologies Ltd.
Sussex Innovation Centre
Science Park Square
Falmer, BN1 9SB
United Kingdom



Reply by jayasooriah July 20, 20062006-07-20
--- In l..., "Mikropaja" wrote:
> Are you sure it's LPC that is dropping the characters?
> Not FTDI with only 128 byte transmit buffer?

Yes it does. Confirmed with CRO trace, and using only 10 character
string.

> More errors on lower speed would be explained quite naturally?

It is not more errors on lower speed, but errors on exact baud rate
multiples. Means host and DUT must have exact crystal multiples.

Deviate the speeds by as little as 0.3% and the problem goes away
meaning the UART behaves as it should and does not drop characters
without setting error bits in status register.

Note baud rate sync is easier at lower bauds than in higher bauds and
this appears to be the reason why it is more apparent on lower bauds.

Note also that if you do not have compatible crystals, you will not be
able to reproduce the results.

Jaya