Lpc2000

Hi Milos,

Didn't know you were into LPC2000 :-)
Did my SOS port run OK then on CrossWorks MSP430 ?

I find CrossWorks' CTL _that_ much better again !
Very fast context switch -AND- very simple event setting/clearing
from within an ISR (no special Kernel entry/exit needed) to
signal the tasks.

regards,
Kris

----- Original Message -----

From: "Milos Prokic" <mproki@...>
To: <lpc2000@yahoogroups.com>
Sent: Tuesday, April 20, 2004 12:39 PM
Subject: [lpc2000] ARM-ELF-GCC and Malloc


> Hi, in my message from yesterday I forgot to specify that the compiler of
> choice is arm-elf-gcc. Please, anyone having any experience in how to get
> the malloc to work properly under this compiler/linker please let me know.
>
> Thank you all very much,
>
> Milos
>
>

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?

TIA to all responders...

Curt

> 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

Kris,

I added an assembler harness to accept the default irq, loaded up
VICDefVectAddr with its address, and let it fly.  The default handler is
being called periodically (it just prints a diagnostic and returns) so
it appears to be working- I can't give a definitive answer until it runs
for a couple of hours, but so far so good.  Thanks so much for your
insight.

Curt

-----Original Message-----
From: microbit [mailto:microbit@...] 
Sent: Monday, April 19, 2004 9:28 PM
To: lpc2000@yahoogroups.com
Subject: Re: [lpc2000] Disabling/enabling interrupt causing a data abort



> 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




 
Yahoo! Groups Links

In general, I'd say it is better to use global interrupt 
enable/disable than doing this in the VIC.

See http://www.arm.com/support/faqip/3677.html

IMHO, getting defualt IRQs is a way to clean up/detect spiruous 
activity rather than the normal way of doiing things.


--- In lpc2000@yahoogroups.com, "Curt Powell" <curt.powell@s...> 
wrote:
> Kris,
> 
> I added an assembler harness to accept the default irq, loaded up
> VICDefVectAddr with its address, and let it fly.  The default 
handler is
> being called periodically (it just prints a diagnostic and returns) 
so
> it appears to be working- I can't give a definitive answer until it 
runs
> for a couple of hours, but so far so good.  Thanks so much for your
> insight.
> 
> Curt
> 
> -----Original Message-----
> From: microbit [mailto:microbit@c...] 
> Sent: Monday, April 19, 2004 9:28 PM
> To: lpc2000@yahoogroups.com
> Subject: Re: [lpc2000] Disabling/enabling interrupt causing a data 
abort
> 
> 
> 
> > 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
> 
> 
> 
> 
>  
> Yahoo! Groups Links

Thanks,
just got on line, and in interim I had a post in Out box with a copy of
Bill's advice
and referred to the original thread I started, which correlates with your
advice.
That's certainly how I ended up leaving my RS232 low level abstraction.
I haven't seen any issues anymore (I think).
This is on my LPC2000 Basic interpeter.

-- Kris


----- Original Message -----

From: "embeddedjanitor" <manningc2@...>
To: <lpc2000@yahoogroups.com>
Sent: Tuesday, April 20, 2004 5:35 PM
Subject: [lpc2000] Re: Disabling/enabling interrupt causing a data abort


> In general, I'd say it is better to use global interrupt
> enable/disable than doing this in the VIC.
>
> See http://www.arm.com/support/faqip/3677.html
>
> IMHO, getting defualt IRQs is a way to clean up/detect spiruous
> activity rather than the normal way of doiing things.
>
>
> --- In lpc2000@yahoogroups.com, "Curt Powell" <curt.powell@s...>
> wrote:
> > Kris,
> >
> > I added an assembler harness to accept the default irq, loaded up
> > VICDefVectAddr with its address, and let it fly.  The default
> handler is
> > being called periodically (it just prints a diagnostic and returns)
> so
> > it appears to be working- I can't give a definitive answer until it
> runs
> > for a couple of hours, but so far so good.  Thanks so much for your
> > insight.
> >
> > Curt