Lpc2000

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@yahoogroups.com, "gerhard_uttenthaler"
<gerhard.uttenthaler@g...> wrote:
> --- In lpc2000@yahoogroups.com, "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