At 05:55 PM 10/8/04 +0000, you wrote:
>--- 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.
OK, but where in the interrupt?
> >
> > 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.
No, switch does not work that way. It is an exact match, not a bit
mask. And having multiple bits set is not only possible but likely, at the
very least TEMT and THRE are often on simultaneously.
>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.
Ah, there is no separate LSR status bit for character timeout. All that
happens is IIR gets set to indicate a received character and trigger an
interrupt. LSR will simply indicate via RBR. The LSR does not 'pay
attention' to the threshold level, RBR will be set as long as at least one
character is 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.
This is not a matter of vectored or not.
> >
> > 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).
Then the increment is unneeded (and could be optimized out anyway). In any
case there is virtually no chance of this working until you fix the switch
statement (well eliminate the switch statement).
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, IIIMessage
Re: [lpc2000] Re: Problems w/ UART
2004-10-08 by Robert Adsett
Attachments
- No local attachments were found for this message.