Hi Stephen,
Have a look at my earlier reply as I am pretty sure that this is the
reason for your polled code failing. The uart is a state machine driven
by a clock of 1.8432MHz for 115200 baud. That's 542ns per clock compared
to the cpu which runs around 17ns per clock and even on the VPB bus that
is still a lot faster than the uart can update it's own registers and
status bits.

Glad to hear you are "hearing" some nice pings, I have still to tackle
the ethernet & LPC combination and I always welcome any feedback.

*Peter*

Stephen Pelc wrote:
> Some while ago I wrote:
> ======================> While testing a Flash copy routine for an LPC2138, I foolishly
> inserted some test code and ran into the following problem.
>
> 1) The code runs in RAM
> 2) 14.7... MHz XTAL, clock = xtal*4, VPBDIV=1
> 3) All interrupts disabled
> 4) UART0 at 115200 baud.
>
> If the UART character transmit loop is too tight when sending a
> string, transmission fails.
> =====================>
> Now back from site, I looked at this some more. After separating
> the code and data by few hundred bytes, the problem went away
> and I was able to remove any delays.
>
> Naturally our/my own code is the most likely culprit. Despite
> much poring over the code ... no bug found (yet). I can see a
> long session with the JTAG unit coming up.
>
> Sorry to have wasted your time.
>
> But I'm pleased to say that the 2148/DM9000 combination is
> happily reading RFID tags and SPI data keys and sending the data
> to a remote website. For a simple test poll of the website,
> opening a connection, sending the request, receiving the
> processed response and closing the connection takes around 70 ms
> from this site. Pinging google.co.uk from my PC here averages 91
> ms and pinging my ISP takes 21 ms.
>
> Stephen
> P.S. If you have to do any work on RFID tags, do not put too
> many laptops close to the reader coils!
> --
> Stephen Pelc, s...@mpeforth.com
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web: http://www.mpeforth.com - free VFX Forth downloads

An Engineer's Guide to the LPC2100 Series

Some while ago I wrote:
======================While testing a Flash copy routine for an LPC2138, I foolishly
inserted some test code and ran into the following problem.

1) The code runs in RAM
2) 14.7... MHz XTAL, clock = xtal*4, VPBDIV=1
3) All interrupts disabled
4) UART0 at 115200 baud.

If the UART character transmit loop is too tight when sending a
string, transmission fails.
=====================
Now back from site, I looked at this some more. After separating
the code and data by few hundred bytes, the problem went away
and I was able to remove any delays.

Naturally our/my own code is the most likely culprit. Despite
much poring over the code ... no bug found (yet). I can see a
long session with the JTAG unit coming up.

Sorry to have wasted your time.

But I'm pleased to say that the 2148/DM9000 combination is
happily reading RFID tags and SPI data keys and sending the data
to a remote website. For a simple test poll of the website,
opening a connection, sending the request, receiving the
processed response and closing the connection takes around 70 ms
from this site. Pinging google.co.uk from my PC here averages 91
ms and pinging my ISP takes 21 ms.

Stephen
P.S. If you have to do any work on RFID tags, do not put too
many laptops close to the reader coils!
--
Stephen Pelc, s...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

--- In l..., stephen@... wrote:
> > I am seeing TDRE and THRE set in R0 and both these bits clear in R4 as
> > one would expect. Am I misreading the problem?
>
> I don't think so, but can't do any more tests until next week.
>
> Stephen

I have seen a similar problem where when UART receiver drops
characters without any errors whatsoever at lower (9600 and below)
baud rates, but worked perfectly at high (up to 230400) baud rates.

The problem was resolved by getting the device that was talking to the
UART to send a longer stop bit as it being a CPLD. I dismissed it as
the UART implementation issue on the CPLD, but I see a number of posts
here about UART problems, in particular missing characters.

I thought I try an experiment to see if I can reproduce the problem.

My program is quite simple: just reads and buffers an entire line of
text and then prints it out upon receiving the end of line.

This program works perfectly at high baud rates. It also works
perfectly at low baud rates when I type the text manually. However if
I cut and paste a line of text, I get only the last character of the
line. Despite detecting errors (uartRead() will return 0 on error), I
am not getting any errors.

I have not bothered to put a CRO on the RxD line to confirm that there
is nothing going wrong between the PC and FTDIchip that is causing
this. The same FTDI chip on non-LPC targets does not exhibit this
behaviour anyway. It would be useful to try this on your setup to see
happens.

My test code follows.

Jaya

> char line[32];
> int posn;
>
> posn = 0;
> for (;;)
> {
> int data;
>
> data = uartRead();
>
> if (data != '\n')
> {
> line[posn] = data;
> posn += 1;
> if (posn >= sizeof (line))
> {
> posn -= 1;
> break;
> }
> continue;
> }
>
> line[posn] = 0;
> showText(line);
> uartSend('\n');
> posn = 0;
> }

Jaya wrote:

> Source:
>
>> lsr1 = _UART0.lsr;
>> _UART0.thr = ' ';
>> lsr2 = _UART0.lsr;
>
> Assembler Output:
>
>> ldr r0, [r1, #20]
>> str r3, [r1]
>> ldr r4, [r1, #20]
>
> The above was for LPC2292, 14.7456 MHz crystal, CPU clock x4, VPB
> divider is 1, MAM is enabled, UART at 230400 baud, 16-bit code in RAM.
>
> I am seeing TDRE and THRE set in R0 and both these bits clear in R4 as
> one would expect. Am I misreading the problem?

I don't think so, but can't do any more tests until next week.

Stephen

At 11:37 AM 7/13/2006 +1000, Bruce Paterson wrote:
>So is this what the Uart driver does in newlib_lpc ? or does that
>driver "effectively" bypass the FIFO ?
>It's been a while since I visited that code !
Strangely enough it uses the bypass technique. I'll have to update
that. It'd be a good time to do that test I mentioned. The code I
mentioned using the fill the buffer technique is in another project.

Won't make much difference to the polled version but should improve the
efficiency of the interrupt version.

Robert
" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

So is this what the Uart driver does in newlib_lpc ? or does that
driver "effectively" bypass the FIFO ?
It's been a while since I visited that code !

________________________________

From: l... [mailto:l...]
On Behalf Of Robert Adsett
Sent: Thursday, 13 July 2006 3:44 AM
To: l...
Subject: Re: [lpc2000] Re: LPC2138 UART bug or docs problem?

Quoting brendanmurphy37 >:
> Rather than continue with this thread, can I suggest we all
agree
> with the following conclusions:
>
> - THRE bit set means "FIFO is empty"
> - Therefore testing for it being set means its OK to write up
to 16
> bytes to the THR
> - The Philips UM is at best ambiguous in its description of
THRE

Sounds right.

> - None of us has actaully verified the exact behaviour, but
we've no
> reason to doubt it doesn't behave this way (i.e. same as
"standard"
> 16550)

I've done some since I'm assuming in my code that THRE flag
means the FIFO is
empty and stuff multiple characters in. I'm not losing any
characters
so there
has to be room available. Nothing definitive though, for that
I'd want
to do a
specific test filling the FIFO with 16 characters on each
interrupt or THRE
flag setting at a slow baud rate (so no characters can be
completely
sent while
the FIFO is being filled).

Robert

--- In l..., "Stephen Pelc" wrote:
>
> While testing a Flash copy routine for an LPC2138, I foolishly
> inserted some test code and ran into the following problem.
>
> 1) The code runs in RAM
> 2) 14.7... MHz XTAL, clock = xtal*4, VPBDIV=1
> 3) All interrupts disabled
> 4) UART0 at 115200 baud.
>
> If the UART character transmit loop is too tight when sending a
> string, transmission fails.
>
> dis emit
> EMIT
> ( 4000.02DC 24801FE5 $..e ) ldr r8, [ pc, # $-24 ] (
> @$400002C0 = $E000C000 )
> ( 4000.02E0 04A02CE5 . ,e ) str r10, [ r12, # $-04 ] !
> ( 4000.02E4 08A0A0E1 . a ) mov r10, r8
> ( 4000.02E8 14809AE5 ...e ) ldr r8, [ r10, # $14 ]
> ( 4000.02EC 208018E2 ..b ) and .s r8, r8, # $20
> ( 4000.02F0 FCFFFF0A |... ) b .eq # $400002E8
> ( 4000.02F4 00009CE5 ...e ) ldr r0, [ r12, # $00 ]
> ( 4000.02F8 00008AE5 ...e ) str r0, [ r10, # $00 ]
> ( 4000.02FC 0000A0E1 .. a ) mov r0, r0
> ( 4000.0300 0000A0E1 .. a ) mov r0, r0
> ( 4000.0304 0000A0E1 .. a ) mov r0, r0
> ( 4000.0308 0000A0E1 .. a ) mov r0, r0
> ( 4000.030C 04A09CE5 . .e ) ldr r10, [ r12, # $04 ]
> ( 4000.0310 08C08CE2 .@.b ) add r12, r12, # $08
> ( 4000.0314 0EF0A0E1 .p a ) mov pc, r14
> 60 bytes, 15 instructions.
>
> The four "mov r0, r0" noops are ncessary for correct operation.
> It appears that one must wait at least a complete VPB cycle or
> two or so after writing the THR register before LSR changes.
>
> Is this behaviour documented somewhere?

Stephen, here is my experiment:

Source:

> lsr1 = _UART0.lsr;
> _UART0.thr = ' ';
> lsr2 = _UART0.lsr;

Assembler Output:

> ldr r0, [r1, #20]
> str r3, [r1]
> ldr r4, [r1, #20]

The above was for LPC2292, 14.7456 MHz crystal, CPU clock x4, VPB
divider is 1, MAM is enabled, UART at 230400 baud, 16-bit code in RAM.

I am seeing TDRE and THRE set in R0 and both these bits clear in R4 as
one would expect. Am I misreading the problem?

Jaya

>
> Stephen
> --
> Stephen Pelc, stephen@...
> MicroProcessor Engineering Ltd - More Real, Less Time
> 133 Hill Lane, Southampton SO15 5AF, England
> tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
> web: http://www.mpeforth.com - free VFX Forth downloads

Quoting brendanmurphy37 :
> Rather than continue with this thread, can I suggest we all agree
> with the following conclusions:
>
> - THRE bit set means "FIFO is empty"
> - Therefore testing for it being set means its OK to write up to 16
> bytes to the THR
> - The Philips UM is at best ambiguous in its description of THRE

Sounds right.

> - None of us has actaully verified the exact behaviour, but we've no
> reason to doubt it doesn't behave this way (i.e. same as "standard"
> 16550)

I've done some since I'm assuming in my code that THRE flag means the FIFO is
empty and stuff multiple characters in. I'm not losing any characters
so there
has to be room available. Nothing definitive though, for that I'd want
to do a
specific test filling the FIFO with 16 characters on each interrupt or THRE
flag setting at a slow baud rate (so no characters can be completely
sent while
the FIFO is being filled).

Robert

--- In l..., Robert Adsett
wrote:
>
> Quoting brendanmurphy37 :
>
> > By the way, can you explain your statement that a "tight loop on
THRE
> > will bypass the FIFO"? Do you mean that the following can fail:
> >
> > Line 1: LOOP:
> > Line 2: THRE bit set?
> > Line 3: IF NOT SET GOTO LOOP
> > Line 4: OK to write THR here! (up to 16-bytes if FIFO enabled)
> >
> > I'd assume that this would always work OK.
>
> So would I.
>
> I meant something like
>
> Line 1: LOOP:
> Line 2: THRE bit set?
> Line 3: IF NOT SET GOTO LOOP
> Line 4: Write to THR
> Line 5: GOTO LOOP
>
> should never write more than one character to the FIFO, thus
bypassing it (at
> least its fuctionality).
>

OK - I understand your comment on bypassing the FIFO now.

Rather than continue with this thread, can I suggest we all agree
with the following conclusions:

- THRE bit set means "FIFO is empty"
- Therefore testing for it being set means its OK to write up to 16
bytes to the THR
- The Philips UM is at best ambiguous in its description of THRE
- None of us has actaully verified the exact behaviour, but we've no
reason to doubt it doesn't behave this way (i.e. same as "standard"
16550)

Brendan.

Quoting brendanmurphy37 :

> --- In l..., "rtstofer" wrote:
>
>> I believe it is correct to test THRE before every character write
>> because it will reflect the status of the top of the FIFO regardless
>> of what is happening with the THRE interrupt. This according to Table
>> 84 (page 92).
>> I'd agree: I read it that it's always correct to test THRE before every
> character and that if it's set it's OK to write the FIFO.

Well, it's not wrong to test THRE, just inefficient.
> The ambiguity comes from whether the bit set means "ther's space in the
> FIFO", which is a natural interpretation of the Philips UM or "the FIFO
> is empty", which is an explicit statement in the NS and similar data
> sheets.
>
> Which is it? or am I completely misreading what you and Robert are
> saying?

I don't think so. I do believe it's following stand '550 practice. If for no
other reason than if it didn't I'd expect to see evidence of overflows from
stuffing 16 characters into a partially full FIFO.

Also it seems odd they would claim '550 compatibility and then break it
in that
fashion. Not that that's ever happed before of course :)

Robert