Lpc2000

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
> First a question, you say the interrupt is not being generated, how
do you 
> know?
> 
While I was debugging w/ JTAG, I put a breakpoint in the isr, it was
never reached.  I'd turn on an LED if one existed for my dev board.


> 
> This is potentially a very big problem.  The LSR can (and often
will) have 
> multiple bits set, so you will almost always be taking the default case 
> even if THRE is set (thus my question above).  Given that the
default case 
> is echoing whatever is in U0RBR (BTW what is CTI?) I would expect
almost 
> anything if no characters had been sent to the port.  Change this
before 
> trying anything else.  Then put a pin toggle or something in so you
know if 
> the interrupt routine is ever reached.
> 
I think that it would rarely take the default case since it would
match the first one and then break.

In previous version I tried enabling all of the interrupts in U0IIR,
the ISR still didn't work, so I was trying something different here.

CTI is character time out.  It will generate the RBR interrupt even if
the threshold has not been reached after 3.5-4.5 character times, so
you know you have data waiting.


> 
> This is potentially a problem.  I haven't looked at in detail but
you are 
> using the same buffer routine here as you are in the non-interrupt 
> code.  The ground is very unstable here.
I removed the vectored irq setup, still doesn't work.

> 
> And if U0IIR is read and used you don't need this line.  In fact if
U0IIR 
> is declared volatile (as it should be) you only would need this line
if the 
> compiler was buggy.

It is defined as volatile (using keil's development tools).