Forums

Interrupts run but main program halts

Started by sengoontoh August 3, 2005
I've a program running interrupts on both UART0 and UART1 as well as a
Match timer interrupt. All interrupts are routed through the VIC with
Timer0 having slot 0, uart0 and uart1 having slot 1 and 2
respectively. When my application starts getting busy with lots of
activity on uart 1 and uart 0, it hangs. The interrupts continue to
work flawlessly. You can even trace through them in IAR. However every
single time I break, I'm in an interrupt handler. Occasionally I'm in
the low level program startup code. Does anyone have any idea what
would cause this behavior.

Also I had a question about resetting the Vic. I'm doing
VicVectorAddres s = 0. I've seen people setting it to 0xff. Which one
is correct?

Thanks!


An Engineer's Guide to the LPC2100 Series



It sounds like you have a lot working correctly and the design sounds
basically correct.
Are you trying to nest interrupts? It is safest to not re-arm
interrupts until exiting the ISR. This defeats some of the advantage of
the VIC - but keeps the software simple. If you do allow nested
interrupts, you need to push all registers - not just R0-R7.
You say that you end up in the startup code from time to time. Does the
system continue to run? Some designs may purposely re-use the startup
code? Or are you hanging in one of the exception handlers and looping
there?
As for the value written to the VIC, any value can be written. The data
is "don't care" - the act of writing clears the interrupt to the VIC.
You might want to also look at the section on Spurious Interrupts in the
LPC/VIC documentation. The problem occurs with peripherals that have
multiple source encoded into one word. These are cleared with
non-atomic read/modify/write sequences. It is possible that a new
interrupt will post after the read. When written back, the interrupt
will be cleared and missed forever. This is discussed in the errata
sheet for LPC21xx.

_____

From: lpc2000@lpc2... [mailto:lpc2000@lpc2...] On Behalf
Of sengoontoh
Sent: Wednesday, August 03, 2005 6:30 AM
To: lpc2000@lpc2...
Subject: [lpc2000] Interrupts run but main program halts
I've a program running interrupts on both UART0 and UART1 as well as a
Match timer interrupt. All interrupts are routed through the VIC with
Timer0 having slot 0, uart0 and uart1 having slot 1 and 2
respectively. When my application starts getting busy with lots of
activity on uart 1 and uart 0, it hangs. The interrupts continue to
work flawlessly. You can even trace through them in IAR. However every
single time I break, I'm in an interrupt handler. Occasionally I'm in
the low level program startup code. Does anyone have any idea what
would cause this behavior.

Also I had a question about resetting the Vic. I'm doing
VicVectorAddres s = 0. I've seen people setting it to 0xff. Which one
is correct?

Thanks! _____

> .
_____


--- In lpc2000@lpc2..., "sengoontoh" <sengoontoh@y...> wrote:
> I've a program running interrupts on both UART0 and UART1 as well
> as a
> Match timer interrupt. All interrupts are routed through the VIC
> with
> Timer0 having slot 0, uart0 and uart1 having slot 1 and 2
> respectively. When my application starts getting busy with lots of
> activity on uart 1 and uart 0, it hangs. The interrupts continue to
> work flawlessly. You can even trace through them in IAR. However
> every
> single time I break, I'm in an interrupt handler. Occasionally I'm
> in
> the low level program startup code. Does anyone have any idea what
> would cause this behavior.
>
> Also I had a question about resetting the Vic. I'm doing
> VicVectorAddres s = 0. I've seen people setting it to 0xff. Which
> one
> is correct?
>
> Thanks!

I've had a similiar problem recently. If you have variables, which are
written in your interrupt routines you have to declare them volatile.
And in your main loop you may have to access this variables atomicly.
This is what helped me.

Gerhard


Thanks for the advice. I went in and put volatile keywords on shared
variables and also made sure my access/reads were atomic. Seems to
have worked. I did get some complains about volatile access sequence
from the compiler. Is there anyway to specify the order of access
other than doing it in a few lines?

With the interrupts running continuously, it turns out that it was
firing the default handler which I had installed but not serviced.
What happened was I thought I could disable the UART interrupt by just
turning off the bit in the VIC but what happens when you do that is
the interrupt gets routed to the default handler.

--- In lpc2000@lpc2..., "gerhard_uttenthaler"
<gerhard.uttenthaler@g...> wrote:
> --- In lpc2000@lpc2..., "sengoontoh" <sengoontoh@y...> wrote:
> > I've a program running interrupts on both UART0 and UART1 as well
> > as a
> > Match timer interrupt. All interrupts are routed through the VIC
> > with
> > Timer0 having slot 0, uart0 and uart1 having slot 1 and 2
> > respectively. When my application starts getting busy with lots of
> > activity on uart 1 and uart 0, it hangs. The interrupts continue to
> > work flawlessly. You can even trace through them in IAR. However
> > every
> > single time I break, I'm in an interrupt handler. Occasionally I'm
> > in
> > the low level program startup code. Does anyone have any idea what
> > would cause this behavior.
> >
> > Also I had a question about resetting the Vic. I'm doing
> > VicVectorAddres s = 0. I've seen people setting it to 0xff. Which
> > one
> > is correct?
> >
> > Thanks!
>
> I've had a similiar problem recently. If you have variables, which are
> written in your interrupt routines you have to declare them volatile.
> And in your main loop you may have to access this variables atomicly.
> This is what helped me.
>
> Gerhard


The way I found around the compiler complaints was to transfer some
of the volatile variable to a local non-volatile variable. This is a
minor pain but it helps avoid issues. This is also good practice if
you are doing several operations using the same variable over several
lines. Example you don't want the variable to change right before
you do a divide but after you do a check to ensure its not zero.
Disabling interrupts can accomplish the same thing but it usually
does not remove the warnings (at least not in my compiler) and you
are forced to disable the interrupts (usually a negative).

If anyone else has better ways to accomplish the same I wouldn't mind
knowing myself but transfering it is the easiest way I found to solve
the issue.

--- In lpc2000@lpc2..., "sengoontoh" <sengoontoh@y...> wrote:
> Thanks for the advice. I went in and put volatile keywords on shared
> variables and also made sure my access/reads were atomic. Seems to
> have worked. I did get some complains about volatile access sequence
> from the compiler. Is there anyway to specify the order of access
> other than doing it in a few lines?
>
> With the interrupts running continuously, it turns out that it was
> firing the default handler which I had installed but not serviced.
> What happened was I thought I could disable the UART interrupt by
just
> turning off the bit in the VIC but what happens when you do that is
> the interrupt gets routed to the default handler.
>
> --- In lpc2000@lpc2..., "gerhard_uttenthaler"
> <gerhard.uttenthaler@g...> wrote:
> > --- In lpc2000@lpc2..., "sengoontoh" <sengoontoh@y...>
wrote:
> > > I've a program running interrupts on both UART0 and UART1 as
well
> > > as a
> > > Match timer interrupt. All interrupts are routed through the VIC
> > > with
> > > Timer0 having slot 0, uart0 and uart1 having slot 1 and 2
> > > respectively. When my application starts getting busy with lots
of
> > > activity on uart 1 and uart 0, it hangs. The interrupts
continue to
> > > work flawlessly. You can even trace through them in IAR. However
> > > every
> > > single time I break, I'm in an interrupt handler. Occasionally
I'm
> > > in
> > > the low level program startup code. Does anyone have any idea
what
> > > would cause this behavior.
> > >
> > > Also I had a question about resetting the Vic. I'm doing
> > > VicVectorAddres s = 0. I've seen people setting it to 0xff.
Which
> > > one
> > > is correct?
> > >
> > > Thanks!
> >
> > I've had a similiar problem recently. If you have variables,
which are
> > written in your interrupt routines you have to declare them
volatile.
> > And in your main loop you may have to access this variables
atomicly.
> > This is what helped me.
> >
> > Gerhard