Re: LPC2000 UART drops characters silently?

Started by Leon Heller July 19, 2006
--- 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?



An Engineer's Guide to the LPC2100 Series

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

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