Lpc2000

> All,
>
> I have  a process receiving data from an rf modem (currently running at
> 4800 baud) using EXTINT2.  The data is clocked into a byte and complete
> bytes are placed into a temporary holding buffer.  The main thread
> periodically pulls the data from the holding buffer into a larger buffer
> in order to perform operations on it (bit shifts, etc.).  I've been
> receiving data abort exceptions periodically on this process.  Turns out
> that I was disabling EXTINT2 prior to pulling data from the temp buffer
> and reenabling EXTINT2 immediately afterwards.  This disabling/enabling
> is what is causing the exception, i.e. if I remove the disable/reenable
> the problem goes away as far as I can tell.  I am disabling by writing
> 0x10000 to VICIntEnClr (0xfffff014), enabling by writing 0x10000 to
> VICIntEnable (0xfffff010).
>
> Two questions:
>
> 1.  Is this the correct approach for disabling/reenabling EXTINT2?
> 2.  Can anyone venture a guess why disabling/enabling EXTINT2 would
> cause a data abort?

I had a similar thing happening with circular buffers for UART operation.
When you're enabling/disabling INTs, the VIC apparently can produce
"spurious" INTs, in that an interrupt can occur while it is being disabled -
hence ...  Default_IRQ() has to handle it.

If you don't have a proper vector handler there that handles the interrupt
going thru the default channel, your code might be causing execution to
land in the land of lala, somewhere. (thus the Dabort)
My suggestion (FWIW) : 1. check you have a proper default_IRQ handler
present.
2. put then a breakpoint on it, and see if you're hitting the default IRQ.
3. Then you can either handle the exception in default_IRQ, or
enable/disable
INTs globally to avoid it.

Try that ?

Cheers,
Kris