Forums

Re: LPC2000 UART drops characters silently?

Started by Leon Heller July 19, 2006
--- In l..., Robert Adsett wrote:

> Oh, and you do need to check bit time not crystal frequency.
> The later doesn't really tell you much except that your source
> is stable.

>From the above and a previous comment by Robert, it sounds like only
Roert and I are prepared to recognise an "anomaly" in the UART design
in relation to stop bit handling. Sigh!

Jaya

An Engineer's Guide to the LPC2100 Series

--- In l..., Robert Adsett wrote:

> Oh, and you do need to check bit time not crystal frequency.
> The later doesn't really tell you much except that your source
> is stable.

>From the above and a previous comment by Robert, it sounds like only
Roert and I are prepared to recognise an "anomaly" in the UART design
in relation to stop bit handling. Sigh!

Jaya

----- Original Message -----
From: "jayasooriah"
To:
Sent: Thursday, July 20, 2006 4:25 AM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
> --- In l..., "Leon Heller" wrote:
>>
>> You don't need anything special for measuring the frequency
>> accurately, I used a low-cost counter made for amateur radio
>> applications. Any decent electronics lab should have something
>> similar.
>
> Sorry I misunderstood you as saying I needed crystal precision
> counter. My 4-digit counter shows 14.74 and ocassionally 14.75 MHz.
>
>> > Will this explain why UART designs detect but not report stop bit
>> > violation?
>>
>> I'm not sure, but it's worth checking as it is so simple, and it's
>> fundamental to the UART timing.
>
> This is where I am trying to understand what you alude to as "counter
> intuitive" phenomenon. Is this related to accuracy or stability of
> the crystal?

Clock accuracy is more important at low baud rates than high rates.
Intuitively, most people would think it's the other way round.

>
> On the board I see the caps there where the should be. I cannot read
> the cap values but design document says 15pf on either ends of the
> crystal.

Philips recommends larger values than that, depending on the crystal load
capacitance. For the LPC2148, at 10-15 MHz with a 20 pF load capacitance
crystal (the usual value), Philips suggests 38 pF capacitors. For a 30 pF
crystal, they should be 58 pF.

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

----- Original Message -----
From: "jayasooriah"
To:
Sent: Thursday, July 20, 2006 4:54 AM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
> --- In l..., Robert Adsett wrote:
>
>> Oh, and you do need to check bit time not crystal frequency.
>> The later doesn't really tell you much except that your source
>> is stable.
>
> From the above and a previous comment by Robert, it sounds like only
> Roert and I are prepared to recognise an "anomaly" in the UART design
> in relation to stop bit handling. Sigh!

I've just tried a simple test with one of my LPC2106 boards at 300 baud
(8n1), using UART0 - filling a buffer with 100 bytes sent from the PC then
transmitting them back again from the buffer, then sending them from the
buffer to the debug I/O terminal. I'm not losing any characters. I forget
which chip you are using, but I doubt if the UART is any different.

Leon

--- In l..., "Leon Heller" wrote:
>
> I've just tried a simple test with one of my LPC2106 boards at 300 baud
> (8n1), using UART0 - filling a buffer with 100 bytes sent from the
PC then
> transmitting them back again from the buffer, then sending them from
the
> buffer to the debug I/O terminal. I'm not losing any characters. I
forget
> which chip you are using, but I doubt if the UART is any different.
>
> Leon

What is the purpose of your test? Is it to show the UART can work
without errors at 300 baud, or to show that the UART will always work
without errors at 300 baud no matter how tight are the transmitted
frames are?

Your test confirms that for your system (and systems like yours) the
your program (and programs like yours) does not see character losses.

Suppose for argument sake, the UART indeed samples the stop bit at the
end of the last bit cell (and not the middle of the bit cell is it
should), would you expect your tests to fail? Deterministically?

Indeed, if was that easy to demonstrate the problem it would have made
it in the errata by now. As far as I am concerned the issue is simply
this:

a) Is the LPC UART is capable of detecting framing errors?

b) What happens when it detects a framing error (reports it or drops it)?

c) Has anyone ever seen the FE bit set in their system in UART0 LSR?

d) What happens in your system if you run my UART-TEST? Do you lose
characters when you paste 8 characters at 230400 baud? What about at
300 baud?

If someone can report that in relation to (c) that it works (or fails)
both at 230400 *and* 300 baud when they run my UART-TEST, that would
warrant I look more closely at the differences in our two systems.

As far as the initial problem is concerned, and my original diagnosis,
changing the transmitter such that it adds effectively less than half
a stop bit solved the problem.

Regards,

Jaya

PS: My setup: LPC2292 (markings LPC2292FBD144 CD7027 07 TSG0510A),
14.7456 MHz, Boot Loader Version 1.64 (if it matters), FTDI FT232BM
with date code 0231 and 6MHz crystal.

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

Jaya

----- Original Message -----
From: "jayasooriah"
To:
Sent: Thursday, July 20, 2006 7:25 AM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
> --- 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?

I'm not sure, you need to do the sums.

Leon
----- Original Message -----
From: "jayasooriah"
To:
Sent: Thursday, July 20, 2006 6:59 AM
Subject: [lpc2000] Re: LPC2000 UART drops characters silently?
> --- In l..., "Leon Heller" wrote:
>>
>> I've just tried a simple test with one of my LPC2106 boards at 300 baud
>> (8n1), using UART0 - filling a buffer with 100 bytes sent from the
> PC then
>> transmitting them back again from the buffer, then sending them from
> the
>> buffer to the debug I/O terminal. I'm not losing any characters. I
> forget
>> which chip you are using, but I doubt if the UART is any different.
>>
>> Leon
>
> What is the purpose of your test? Is it to show the UART can work
> without errors at 300 baud, or to show that the UART will always work
> without errors at 300 baud no matter how tight are the transmitted
> frames are?
>
> Your test confirms that for your system (and systems like yours) the
> your program (and programs like yours) does not see character losses.

That's all I care about. The frame timing was as tight as it can be.

Leon
--- In l..., "Leon Heller" wrote:

> >
> > As I reported, measured frequency is is 14.74 MHz using a 4-digit
> > counter. Is this measurement not accurate enough?
>
> I'm not sure, you need to do the sums.
>

Please correct me if I am wrong -- my off-the-cuff calcuations:

* Four decimal digit counter with 1 count error is 1 1000 or 0.1%

* Half a bit error over 10 bit frame (1 start, 1 stop, 8-data) yields
error of 1 in 20 or 5%.

This is why I thought my measurement is accurate enough.

Whatever the baud rate, signal is 16x oversampled and I expect the
error rate not to be dependent on baud rate for this reason. You seem
to suggest it may be but I don't believe you explain how. If I knew
how it happens I could go looking for this cause ...

Thanks.

Jaya

--- In l..., "jayasooriah"
wrote:
>
> What is the purpose of your test? Is it to show the UART can work
> without errors at 300 baud, or to show that the UART will always
work
> without errors at 300 baud no matter how tight are the transmitted
> frames are?

I can't answer for Leon, but as someone who's done similar tests
with similar results, here's my answer. The purpose of my tests was
to see if I could reproduce the failure mode you were seeing. The
specific test was to see if the UART always worked at 300 bps
regardless of how tight the transmission on the line was.

My results were very clear. I will repeat them again, as you seemed
to ignore them:

1. If the configuration of both ends of the line matched in terms of
the number of stop bits, there were no errors either present or
detected. The gap between the characters was verified on a scope as
being exactly that expected (i.e. either one or two stop bits,
depending on what configuration was being tested at the time).

2. If the configuration of the line was 8-N-2 on the LPC21xx end and
8-N-1 on the PC end, errors were generated if there was no gap
between the characters sent. As I reported there were three types of
errors seen: (a) incorrect data received with no error status (b)
incorrect data received with frame errors reported and (c) missing
data.

In other words, I can easily reproduce the failure mode you see but
only when the configuration of the UARTs on the line do not match.
As I said, this to me is entirely predictable: if you have a
mismatched configuration, it won't work in some cases, and in some
of those cases not all errors are reported.

There is no test I could do that could reproduce your "drops
characters at low bit rate" problem.

Based on what I've seen, my theory is that there is some issue with
your test system that causes it to use the wrong number of stop bits
in your low bit rate tests, or that the UART configuration is
incorrect at low bit rates.

Do you have a theory as to why I can't reproduce this "drops
characters at low bit rate" problem? So far, all I've seen is "you
aren't filling the line". However, as I've said, I have discounted
this possibility by direct measurement. I can state quite
categorically that the line is as full of data as it can be in all
the tests I've done.

>
> Your test confirms that for your system (and systems like yours)
the
> your program (and programs like yours) does not see character
losses.
>
> Suppose for argument sake, the UART indeed samples the stop bit at
the
> end of the last bit cell (and not the middle of the bit cell is it
> should), would you expect your tests to fail? Deterministically?

My expectation was my tests would match your own results, given they
have the same conditions you describe. Admittedly I'm using a
different variant of the part. However, others have reported the
same results.

>
> Indeed, if was that easy to demonstrate the problem it would have
made
> it in the errata by now. As far as I am concerned the issue is
simply
> this:
>
> a) Is the LPC UART is capable of detecting framing errors?

Yes I've seen them.

>
> b) What happens when it detects a framing error (reports it or
drops it)?
>

I would assume if it detects one it reports it.

> c) Has anyone ever seen the FE bit set in their system in UART0
LSR?
>

Yes. See my original test report, and the text above.

> d) What happens in your system if you run my UART-TEST? Do you
lose
> characters when you paste 8 characters at 230400 baud? What about
at
> 300 baud?

See my original test report. If the configuration of the UARTs
matched on both ends of the line, I did not see any errors: the
program displayed whatever was sent to it at a selection of bit
rates (I tried 300bps to 115.2 kbps). As I said, I verified on a
scope that the line was "full".

>
> If someone can report that in relation to (c) that it works (or
fails)
> both at 230400 *and* 300 baud when they run my UART-TEST, that
would
> warrant I look more closely at the differences in our two systems.

Based on the results I've seen I'd agree with this. If I can get a
slot, I'm willing to do more testing on this. On your side, I would
recommend:

- verify your actual UART settings (e.g. implement a command that
dumps them out)
- run your test at 300bps sending two characters back to back
- verify on a scope the gap between them at the LPC2xxx input pin
(do you know for a fact the FTDI chip gets it right?)

>
> As far as the initial problem is concerned, and my original
diagnosis,
> changing the transmitter such that it adds effectively less than
half
> a stop bit solved the problem.
>

This does not prove the problem is with the LPC21xx UART.

> PS: My setup: LPC2292 (markings LPC2292FBD144 CD7027 07 TSG0510A),
> 14.7456 MHz, Boot Loader Version 1.64 (if it matters), FTDI FT232BM
> with date code 0231 and 6MHz crystal.
>

We have two UARTs on the board I'm using. The first, which I used
for testing, is direct to a MAX232 or similar. The second goes to a
Ti USB IC (I forget which one).

Brendan