Re: LPC2000 UART drops characters silently?
> 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.
Configuring the receive interface differently from the transmit
interface is misconfiguration by definition. It also ignores the
realities of various UART hardware implementations. It may be a valid
test case to determine if the UART's Rx configuration is set for one
stop bit or two, but the results of such a misconfiguration will vary
between different hardware designs. It is possible to design a UART to
be tolerant of stop bit misconfiguration, but it is also valid to
require the correct number of stop bits. The simplest way is to design
the Rx to be always one stop bit, since forcing 1.5 or two stop bits
is really only necessary for the Tx. That said, the error produced by
incorrect stop bit configuration is a framing error and the robustness
of framing error detection also varies in different UART hardware
designs. Using ASCII text as the test data is also a significant
stress condition since the the most significant bit of ASCII text is a
start bit. That could cause problems like the loss of bit
synchronization, which may not recover until the next idle condition.
Put another way, sending one stop bit data when two stop bit data is
configured is a test specifically designed to fail, so there should be
no surprise if it does. It also seems to be a test that is purely
academic, since no software engineer in industry could get such a poor
design past code review.
> 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
> As always, feel free to let me know of errors and/or missions.
> --- 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
Are you sure it's LPC that is dropping the characters?
Not FTDI with only 128 byte transmit buffer?
More errors on lower speed would be explained quite naturally?
> 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
> 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.
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
> 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!)
> 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.
Senior Electronics Engineer
Geola Technologies Ltd.
Sussex Innovation Centre
Science Park Square
Falmer, BN1 9SB
> --- In l..., "Leon Heller" wrote:
>> I'm not sure what error those 15 pF capacitors would give, I could
>> the oscillator and see what I get, but it's easier to measure the
>> I've got the correct value capacitors on my boards and the frequency
> is very
>> close to nominal.
> 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
steps removed from the bit time.
> --- In l..., "brendanmurphy37"
> > 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
> 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.
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.
"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
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
2006 June 16 7
The software reads the old value though and the bit that got set by
hardware is lost."
Read the rest at:
> 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.
> Frankly, anyone making such an absurd statement is an IDIOT!
> > --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
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.
> Frankly, anyone making such an absurd statement is an IDIOT!
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).
> --- In l..., "George M. Gallant, Jr."
> > 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
> 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
> 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
> specifically identified by the errata (framing errors not
> and insists it is a hardware problem (which it is, just not the
> the OP believes).
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
- 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
- if there are errors on the line, not all are detected by a polled
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
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.
P.S. I promise (again!) not to post anything else on this topic....