Lpc2000

Just for clarification on the UART Block Diagram (see UM)...
1. Do U0TSR & U0RSR actually representthe Tx & Rx FIFO buffers? I 
only see U0TSR & U0RSR illustrated here and I can't find any other 
documentation for it.

Now concerning U0THR & U0RBR (data registers)...
2. Why do they both share the same memory address? I'd really like 
to know the purpose of this.

3. What will happen if the lpc receives a character while I'm 
writing to the transmit register?

I ask this because currently, I'm having trouble running the serial 
port both ways (with interrupts) while sending replies and receiving 
command packets from the PC. Sometimes the protocol I'm using works. 
However, while debugging I always notice the lpc losing receiver 
bytes whenever communication goes wrong. I only observe this 
happening if the lpc's replying to a command packet and another 
command packet's coming in the same time.

best regards,
Leighton

At 08:55 PM 11/17/04 +0000, you wrote:
>Now concerning U0THR & U0RBR (data registers)...
>2. Why do they both share the same memory address? I'd really like
>to know the purpose of this.

Consider the R/W line an extra address bit if it helps.  They don't share 
the same physical memory.  The idea (from the 8250 on) is that since you 
never read the transmit register and never write the receive register that 
they can be distinguished simply by the state of the read line and save all 
that extra address space and decoding logic (also explains why the divisor 
latch is a banked register).  These would be from the same school of chip 
designers that believe you never actually need to read setup registers.


>3. What will happen if the lpc receives a character while I'm
>writing to the transmit register?

It's supposed to act just fine.


>I ask this because currently, I'm having trouble running the serial
>port both ways (with interrupts) while sending replies and receiving
>command packets from the PC. Sometimes the protocol I'm using works.
>However, while debugging I always notice the lpc losing receiver
>bytes whenever communication goes wrong. I only observe this
>happening if the lpc's replying to a command packet and another
>command packet's coming in the same time.

Are you sure it's not the other way around?  I have seen a similar problem 
but I keep losing THRE interrupts.  It appears they 'disappear' if the LPC 
receives a byte while the interrupt identification register was being 
read.  I have a work-around that appears to at least reduce the problem 
(I've not had it reappear) that only reads the IIR once per interrupt.

It behaves similarly to the documented race conditions on the LPC 
(particularly the timers) but I've not seen anybody report duplicating it yet.

Needless to say, I'd like to know for sure what's going on with it and you 
seem to have come closest to duplicating the conditions I see it under 
(both interrupts active, transmit and receive happening simultaneously).

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

--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> 
wrote:
> 
> Just for clarification on the UART Block Diagram (see UM)...
> 1. Do U0TSR & U0RSR actually representthe Tx & Rx FIFO buffers? I 
> only see U0TSR & U0RSR illustrated here and I can't find any other 
> documentation for it.

No, they are the actual shift registers.  U0TSR can be checked with 
U0LSR bit 6, TEMT.  TEMT=0 => U0TSR is shifting out a byte, TEMT=1 => 
U0TSR is idle.  The 16-byte FIFOs aren't shown in the figure, but 
would rather correspond to U0THR and U0RBR.  For better 
documentation, Google for 16C550.

 
> Now concerning U0THR & U0RBR (data registers)...
> 2. Why do they both share the same memory address? I'd really like 
> to know the purpose of this.

Writing to the address means writing to U0THR, and reading from the 
address means reading from U0RBR.  They occupy the same address 
because Philips chose to be software compatible with the 16C550, 
which was designed to be hardware and software compatible with the 
8250, which was designed at a time when I/O addresses apparently were 
very precious.  For an even worse example of this mindset, see the 
Intel 8259 interrupt controller which occupies two(!) I/O addresses.
 

> 3. What will happen if the lpc receives a character while I'm 
> writing to the transmit register?

Nothing special, the receiver and transmitter work independently.  
But make sure that you don't miss any of them in your interrupt 
handler.


> I ask this because currently, I'm having trouble running the serial 
> port both ways (with interrupts) while sending replies and 
receiving 
> command packets from the PC. Sometimes the protocol I'm using 
works. 
> However, while debugging I always notice the lpc losing receiver 
> bytes whenever communication goes wrong. I only observe this 
> happening if the lpc's replying to a command packet and another 
> command packet's coming in the same time.

When you enable more than one interrupt in U0IER (such as both 
receive and transmit interrupt), you should in your interrupt handler 
check U0IIR to see what caused the interrupt.  More than one 
interrupt can occur at a time, and the highest priority one is 
indicated in U0IIR.

Pay close attention to the "Interrupt Reset" column in the UART0 
Interrupt Handling table.  When you have seen in U0IIR what caused 
the interrupt, you should handle it, and then do the action in 
the "Interrupt Reset" column to tell the UART that you have handled 
it.  For a receive interrupt, the Interrupt Reset action is to 
read U0RBR, so it is a quite normal part of handling a receive 
interrupt.  For a transmit interrupt, the reset action is simply 
reading U0IIR, which you have already done since you know it is a 
transmit interrupt.

If you don't do the Interrupt Reset action in your interrupt handler 
for a pending interrupt, the UART will immediately interrupt again.  
So you can write your interrupt handler in two ways:

a. Check U0IIR, handle the highest-priority pending interrupt, 
thereby doing the Interrupt Reset action, and return.  If more than 
one interrupt was pending, the UART will immediately interrupt again, 
and then present the next-highest priority interrupt in U0IIR, and so 
on.  This way is the easiest, and the best one if multiple 
simultaneous interrupts are rare.

b. Check U0IIR, handle the highest-priority pending interrupt, 
thereby doing the Interrupt Reset action.  Re-check U0IIR, and loop 
around if another interrupt is pending.  When no more interrupts are 
pending, return.  This way is better if multiple simultaneous 
interrupts are so likely that it pays off to save the multiple 
interrupt entry/exit code.


Regards,
Karl Olsen

At 10:07 PM 11/17/04 +0000, you wrote:
>b. Check U0IIR, handle the highest-priority pending interrupt,
>thereby doing the Interrupt Reset action.  Re-check U0IIR, and loop
>around if another interrupt is pending.  When no more interrupts are
>pending, return.  This way is better if multiple simultaneous
>interrupts are so likely that it pays off to save the multiple
>interrupt entry/exit code.

That's certainly the way it's supposed to work (and the way I have done it 
on 'real' 16550s) but when I do this on an LPC2106 with both transmit and 
receive interrupts I occasionally miss THRE interrupts (they just never 
occur).  This only happens when receive is occurring at the same time as 
transmit (I used a simple echo test) and it only occurs infrequently 
(several 100K up to a megabyte or more of transmitted bytes before it would 
halt).  The only explanation I have is an undocumented race condition in 
updating the IIR as it is being read but as I said in an earlier post I 
haven't seen any duplication.  Changing to the less conventional one IIR 
read per interrupt seems to eliminate the problem but maybe all it does is 
reduce the probability.

Leighton's symptoms appear to be similar to (but not the same as) what I've 
seen so I'm wondering if he hasn't run across the same underlying problem I 
have.

The THRE interrupts are the only serial interrupts that do not re-assert if 
they are not serviced so they are particularly vulnerable.

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

Sorry for the delay guys,

Point taken for the answers to 1,2, and 3. Thanks Karl & Robert. 

> Leighton's symptoms appear to be similar to (but not the same as) 
what I've 
> seen so I'm wondering if he hasn't run across the same underlying 
problem I 
> have.
> 
> The THRE interrupts are the only serial interrupts that do not re-
assert if 
> they are not serviced so they are particularly vulnerable.
> 

Robert, I haven't yet seen the problem you described that's 
interestingly the opposite to what I'm getting. Debugging through 
the JTAG and using a serial port data logger I see all the receiver 
bytes coming in from the PC. I usually send up to 16 bytes per THRE 
& for the most part the lpc sends the reply packet correctly. But 
only in that special case I see the lpc not respond to the last 
command packet. It came across the receive line ok (logger) so the 
PC's ok. However on the lpc side I debug and see the packet looking 
truncated. Like some bytes got lost while receiving, which looks 
kinda wierd. I haven't yet seen the opposite happen b4.

> a. Check U0IIR, handle the highest-priority pending interrupt, 
> thereby doing the Interrupt Reset action, and return.  If more 
than 
> one interrupt was pending, the UART will immediately interrupt 
again, 
> and then present the next-highest priority interrupt in U0IIR, and 
so 
> on.  This way is the easiest, and the best one if multiple 
> simultaneous interrupts are rare.
> 
> b. Check U0IIR, handle the highest-priority pending interrupt, 
> thereby doing the Interrupt Reset action.  Re-check U0IIR, and 
loop 
> around if another interrupt is pending.  When no more interrupts 
are 
> pending, return.  This way is better if multiple simultaneous 
> interrupts are so likely that it pays off to save the multiple 
> interrupt entry/exit code.

Interesting stuff Karl. I wasn't really paying attention to the IIR 
table. So, I'll have to review my code just incase I did a bit too 
much for RDA & THRE. Basically, the code I'm using is following Plan 
B. Bill Knight's code follows the same concept too. I'll give Plan A 
a try though, since my PC <-> lpc communication is on a small scale, 
and Robert's having more success with it.

At 02:15 PM 11/18/04 +0000, you wrote:
> > Leighton's symptoms appear to be similar to (but not the same as)
>what I've
> > seen so I'm wondering if he hasn't run across the same underlying
>problem I
> > have.
> >
> > The THRE interrupts are the only serial interrupts that do not re-
>assert if
> > they are not serviced so they are particularly vulnerable.
> >
>
>Robert, I haven't yet seen the problem you described that's
>interestingly the opposite to what I'm getting. Debugging through
>the JTAG and using a serial port data logger I see all the receiver
>bytes coming in from the PC. I usually send up to 16 bytes per THRE
>& for the most part the lpc sends the reply packet correctly. But
>only in that special case I see the lpc not respond to the last
>command packet. It came across the receive line ok (logger) so the
>PC's ok. However on the lpc side I debug and see the packet looking
>truncated. Like some bytes got lost while receiving, which looks
>kinda wierd. I haven't yet seen the opposite happen b4.

I had a thought.  If my speculation about a race condition in IIR is 
correct it may well explain both our problems.  In my case I lose the THRE 
interrupt and thus stop transmitting.  In your case you lose a receive 
interrupt and drop a character.  My test wouldn't catch a dropped character 
since I wasn't running any sort of check or comparison so all I would see 
is if the echo stopped cold (if a receive interrupt was missed it would 
just pick up the next one).

Do you know (and can you tell) if the packet is truncated or maybe just 
missing characters from its body?  If it always just characters at the end 
I'm less optimistic about the race condition.

If it is a race in the IIR then a single read per interrupt might help (or 
it might not) depending on the details of the race and the timing (ICK).

In any case let us know how changing to a single IIR read per interrupt 
affects the problem.


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

> Do you know (and can you tell) if the packet is truncated or maybe 
just 
> missing characters from its body?  If it always just characters at 
the end 
> I'm less optimistic about the race condition.

Well after double checking & changing my code to the single IIR read 
concept, things remained the same. The affected packet I receive 
always get's somewhat truncated in the middle, with the last bytes 
showing up a few bytes earlier than expected. 

I however notice LSR interrupt occuring at the point where the 
problem occurs but I don't see any signs of any LSR errors. 

Just a crazy question though...can the UART ISR interrupt itself?
(eg. while processing a THRE an RDA interrupt comes in)

Should I enable the FIFOs (write 1 to U0FCR) before running the 
interrupts? I seem to be getting by without this up until this point.

Thanks again,
Leighton

At 07:00 PM 11/18/04 +0000, you wrote:
> > Do you know (and can you tell) if the packet is truncated or maybe
>just
> > missing characters from its body?  If it always just characters at
>the end
> > I'm less optimistic about the race condition.
>
>Well after double checking & changing my code to the single IIR read
>concept, things remained the same. The affected packet I receive
>always get's somewhat truncated in the middle, with the last bytes
>showing up a few bytes earlier than expected.

Well that fits with the speculation of an IIR race condition.  Doesn't 
prove it but it does fit.  You may have duplicated what I've been seeing.


>I however notice LSR interrupt occuring at the point where the
>problem occurs but I don't see any signs of any LSR errors.

Hmmm... Doesn't make much sense to me either.  Maybe instead of a simple 
race the source is being miss-classified?  My own test would not have seen 
a difference between that and the interrupt simply dissappearing.


>Just a crazy question though...can the UART ISR interrupt itself?
>(eg. while processing a THRE an RDA interrupt comes in)

At the very least that would require that you re-enable the associated 
interrupt (IRQ or FIQ) and if vectored through the VIC you would also have 
to acknowledge the vectored interrupt with the appropriate write to the VIC 
first as well.   If you've done that, try it again w/o re-enabling the 
interrupts.


>Should I enable the FIFOs (write 1 to U0FCR) before running the
>interrupts? I seem to be getting by without this up until this point.

I don't see why that would eliminate the problem.  Worse it might hide it 
so that it showed up later under less benign conditions.

Curiouser and curiouser
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

> >Should I enable the FIFOs (write 1 to U0FCR) before running the
> >interrupts? I seem to be getting by without this up until this 
point.
> 
> I don't see why that would eliminate the problem.  Worse it might 
hide it 
> so that it showed up later under less benign conditions.
> 

Good news...I got communication running alot better after enabling 
FIFOs (U0FCR = 1) at startup. So far, no Rx & Tx glitches yet. Try 
doing the same to see what happens.

For now the LSR mystery is worth forgetting. 


Leighton

At 08:02 PM 11/18/04 +0000, you wrote:
> > >Should I enable the FIFOs (write 1 to U0FCR) before running the
> > >interrupts? I seem to be getting by without this up until this
>point.
> >
> > I don't see why that would eliminate the problem.  Worse it might
>hide it
> > so that it showed up later under less benign conditions.
> >
>
>Good news...I got communication running alot better after enabling
>FIFOs (U0FCR = 1) at startup. So far, no Rx & Tx glitches yet. Try
>doing the same to see what happens.

That rather worries me.  I will give it try and see what it does on my code 
though (I've got a few other items to take care of first).  I place it in 
the same category as my read-IIR-only-once-per-interrupt 'fix' though.  I 
strongly suspect it's only masking temporarily whatever the underlying 
cause is.

I suspect there is something similar going on here as happens with the SPI 
and the timers.  We've now got two independent reports of missing 
interrupts on the UART with no clear source of the problem.

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

You MUST enable the FIFO (by setting U0FCR:0) - See Description of 
that bit in Table 66 of LPC2106 User Manual.

Since other sections of the manual imply that you can run without 
this bit set, I asked Philips about it.  One of the apps engineers 
told me it was OK to run without the FIFO enabled.  Hwever, another 
apps engineer told me that the original intention was to allow 
operation without the FIFO, but they discovered some bugs operating 
in that mode, so they redefined the product to not allow that mode of 
operation.

So, as far as I know, if the FIFO is not enabled - all bets are off.

Robert: Are you also operating without the FIFO when you have your 
problems?

As to whether the problem operating without the FIFO (which Philips 
has long been aware of) might be caused by a similar race condition 
as the timer interrupt problem - interesting question.  When I 
discussed the FIFO issue with them, the timer problem had not yet 
been discovered.  Now that Philips has an understanding of the timer 
interrupt problem (and has reportedly implemented a fix on some new 
chips in development), their circuit designers should be able to 
easily determine if a similar problem exists here.

In fact, there are a number of other registers which also get written 
to by both the core and peripheral hardware.  Has Philips analyzed 
which of these are subject to the same problem with simultaneoues 
access?

Philips: How about letting us know what's going on!




--- In lpc2000@yahoogroups.com, "Leighton Rowe" <leightonsrowe@y...> 
wrote:

> 
> > >Should I enable the FIFOs (write 1 to U0FCR) before running the
> > >interrupts? I seem to be getting by without this up until this 
> point.
> > 
> > I don't see why that would eliminate the problem.  Worse it might 
> hide it 
> > so that it showed up later under less benign conditions.
> > 
> 
> Good news...I got communication running alot better after enabling 
> FIFOs (U0FCR = 1) at startup. So far, no Rx & Tx glitches yet. Try 
> doing the same to see what happens.
> 
> For now the LSR mystery is worth forgetting. 
> 
> 
> Leighton

Thanks for passing this along.  It may be the root of a problem that's been 
bothering me for some time.  There are times when I start to think Philips 
is actually trying to kill this microcontroller.

At 10:00 PM 11/18/04 +0000, you wrote:
>You MUST enable the FIFO (by setting U0FCR:0) - See Description of
>that bit in Table 66 of LPC2106 User Manual.

Good heavens, that's well hidden.  I don't think very many others noticed 
that.  Most of the example uart code doesn't use the FIFOs.  It's certainly 
contradictory to any other 16550 implementation.

I'll have to go back to my paper copy and see if that was in earlier revs 
of the UM.  Sheesh!



>Since other sections of the manual imply that you can run without
>this bit set, I asked Philips about it.  One of the apps engineers
>told me it was OK to run without the FIFO enabled.  Hwever, another
>apps engineer told me that the original intention was to allow
>operation without the FIFO, but they discovered some bugs operating
>in that mode, so they redefined the product to not allow that mode of
>operation.
>
>So, as far as I know, if the FIFO is not enabled - all bets are off.
>
>Robert: Are you also operating without the FIFO when you have your
>problems?

Nope, the program I've got that ran into the problem has the FIFO 
enabled.  Hmm that went through a set of changes I may have added the FIFO 
after changing the IIR read. I'll have to go back and recheck to see if it 
works properly with the FIFO enabled now.


>As to whether the problem operating without the FIFO (which Philips
>has long been aware of) might be caused by a similar race condition
>as the timer interrupt problem - interesting question.  When I
>discussed the FIFO issue with them, the timer problem had not yet
>been discovered.  Now that Philips has an understanding of the timer
>interrupt problem (and has reportedly implemented a fix on some new
>chips in development), their circuit designers should be able to
>easily determine if a similar problem exists here.

Well, one race condition is an oversight.  Two make me wonder if it was 
something they didn't check for properly.  And since both the SPI and timer 
have documented race conditions (and given the apparent long lead time 
between the discovery of an issue and letting us know about it) ....


>In fact, there are a number of other registers which also get written
>to by both the core and peripheral hardware.  Has Philips analyzed
>which of these are subject to the same problem with simultaneoues
>access?
>
>Philips: How about letting us know what's going on!

Very good question.  Having errata come out in dribs and drabs is very 
frustrating.

I'll get to this shortly, I hope,  and I will report back (after restoring 
IIR multiple read with FIFO's enabled and performing a test).


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

It seems to me that given the problem with the UART interrupt 
register, it is more likely than not that the same problem exists 
with other registers.  Rather than "one race condition is an 
oversight," I would assume similar circuit design would be used in 
all parts of the chip.

In any event, this is something which should be very easy for 
Philips' circuit designers to answer.

As engineers, we can all appreciate that bugs sometimes get through.  
It's the lack of information, once the bug is discovered, that's 
frustrating.


--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> 
> Well, one race condition is an oversight.  Two make me wonder if it 
was 
> something they didn't check for properly.  And since both the SPI 
and timer 
> have documented race conditions (and given the apparent long lead 
time 
> between the discovery of an issue and letting us know about it) ....
> 
> 
> >In fact, there are a number of other registers which also get 
written
> >to by both the core and peripheral hardware.  Has Philips analyzed
> >which of these are subject to the same problem with simultaneoues
> >access?
> >
> >Philips: How about letting us know what's going on!
> 
> Very good question.  Having errata come out in dribs and drabs is 
very 
> frustrating.
>

Hi folks,

First off, I'm using the LPC2294.

I am finding my CAN messages seemingly delayed by one message. In my main loop 
I have:

if ((CAN1GSR  & 0x01) == 0x01)		
		{		
		QueueCAN1Out();		// Queue up the received  message to send out of the UART.
		CAN1CMR |= 0x04;		// Clear the had frame bit
		}

The call to QueueCAN1Out is triggered when I send out a CAN message from an 
external CAN node into the LPC. However, the first message I look at reads 
all its registers as being filled with zeros. If I then send another CAN 
message from the external CAN node, the data and the identifier are what was 
send out by the remote node on the first transmission. The third message  
reads the second message's data and identifier and so on. 

If I insert the line:

	temp = CAN1RID;

into the routine above, just to prove it's not a different part of my code 
that's at fault, the value in temp is always the identifier from the previous 
CAN mesaage. 

Has anyone ever come across this before? I've read through the datasheet and 
nothing seems to indicate why this would happen and I don't see anything in 
the errata sheet either. I have checked with a little CAN analyser and the 
messages being sent out from the external node seem correct. 

I've even tried reading the first message twice to see if I could flush out 
the phantom zeros, but I just read zeros again. It's only when I receive the 
second CAN message that the first message is flushed out. 

Anyone seen anything like this before? And if so, do you know what I'm doing 
wrong?!

Many thanks.

Rob.

Hi Robert,

are you sure, that not another nodes sends any ID before your 
external node ? 
The CAN-Core contains a internal Buffer with about 64 Bytes 
(descriped at  SJA1000, should be the same at LPC ). So if your 
Buffer contains any other data  which were received from a previous 
message, you will get this one.  
In normal case you should receive messages like this :      

while((CAN1GSR  & 0x01) == 0x01) {		
     QueueCAN1Out();
     CAN1CMR |= 0x04;		
}

hope it helps,

Peter






--- In lpc2000@yahoogroups.com, Robert Wood <robert.wood@a...> wrote:
> Hi folks,
> 
> First off, I'm using the LPC2294.
> 
> I am finding my CAN messages seemingly delayed by one message. In 
my main loop 
> I have:
> 
> if ((CAN1GSR  & 0x01) == 0x01)		
> 		{		
> 		QueueCAN1Out();		// Queue up the received  
message to send out of the UART.
> 		CAN1CMR |= 0x04;		// Clear the had 
frame bit
> 		}
> 
> The call to QueueCAN1Out is triggered when I send out a CAN message 
from an 
> external CAN node into the LPC. However, the first message I look 
at reads 
> all its registers as being filled with zeros. If I then send 
another CAN 
> message from the external CAN node, the data and the identifier are 
what was 
> send out by the remote node on the first transmission. The third 
message  
> reads the second message's data and identifier and so on. 
> 
> If I insert the line:
> 
> 	temp = CAN1RID;
> 
> into the routine above, just to prove it's not a different part of 
my code 
> that's at fault, the value in temp is always the identifier from 
the previous 
> CAN mesaage. 
> 
> Has anyone ever come across this before? I've read through the 
datasheet and 
> nothing seems to indicate why this would happen and I don't see 
anything in 
> the errata sheet either. I have checked with a little CAN analyser 
and the 
> messages being sent out from the external node seem correct. 
> 
> I've even tried reading the first message twice to see if I could 
flush out 
> the phantom zeros, but I just read zeros again. It's only when I 
receive the 
> second CAN message that the first message is flushed out. 
> 
> Anyone seen anything like this before? And if so, do you know what 
I'm doing 

> wrong?!
> 
> Many thanks.
> 
> Rob.