Yahoo Groups archive
Thread
2005-11-08 by ee_gary
Hello, I'm having a problem where my code goes into the bushes after ~10 seconds. Running it in the simulator results in a "Non-aligned Access" error, ARM Instruction at 00000200H, Memory Access at 40000241H. Any idea what that means? Simple code, just an interrupt driven timer and interrupt driven SPI Any help is greatly appreciated. Thanks! Gary
2005-11-08 by Tom Walsh
ee_gary wrote: >Hello, > >I'm having a problem where my code goes into the bushes after ~10 >seconds. Running it in the simulator results in a "Non-aligned >Access" error, ARM Instruction at 00000200H, Memory Access at >40000241H. Any idea what that means? Simple code, just an interrupt >driven timer and interrupt driven SPI\ufffd > > > You can run into this when mixing Thumb with ARM code. When interrupt routines are entered, the processor is in ARM mode, either write your handlers in ARM or switch to THUMB mode, process the interrupt, then exit THUMB mode and return from interrupt. FWIW, Thumb, and thumb-internetworking, is too much trouble to deal with, I run strictly ARM mode. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-08 by Charles Manning
On Tuesday 08 November 2005 14:40, Tom Walsh wrote: > ee_gary wrote: > >Hello, > > > >I'm having a problem where my code goes into the bushes after ~10 > >seconds. Running it in the simulator results in a "Non-aligned > >Access" error, ARM Instruction at 00000200H, Memory Access at > >40000241H. Any idea what that means? Simple code, just an interrupt > >driven timer and interrupt driven SPI… > What instruction was this accessing? The following things can give you non-aligned accesses: 1) Trying to read a U32 on a non-4-byte boundary or a U16 on a non-2byte boundary. This might raise a data abort. 2) Trying to execute an ARM instruction at a non-4-byte location or a thumb instruction at a non-2-byte location. This might raise a prefetch abort. > You can run into this when mixing Thumb with ARM code. When interrupt > routines are entered, the processor is in ARM mode, either write your > handlers in ARM or switch to THUMB mode, process the interrupt, then > exit THUMB mode and return from interrupt. Yes, this is possible since thumb addresses are marked by setting the least significant bit. If you try executing the address by using a regular branch or bl then this will break. You need to use a bx. > > FWIW, Thumb, and thumb-internetworking, is too much trouble to deal > with, I run strictly ARM mode. To each their own, but I strongly disagree. I use thumb and interworking a lot. gcc support for this is great. I always write all my assembly with interworking (ie using bx) regardless. For an example you might look at the example stuff I posted on the AT91SAM7 group.
2005-11-08 by Tom Walsh
Charles Manning wrote: >>FWIW, Thumb, and thumb-internetworking, is too much trouble to deal >>with, I run strictly ARM mode. >> >> > >To each their own, but I strongly disagree. I use thumb and interworking a >lot. gcc support for this is great. > >I always write all my assembly with interworking (ie using bx) regardless. > >For an example you might look at the example stuff I posted on the AT91SAM7 >group. > > Doing the Internetworking is a new thing for me, newlib and gcc were at odds with each other over thumb code linking so I removed the ability. I've got a lot of code to write and plenty of room to work with right now, perhaps later I will consider moving into Thumb. Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-08 by embeddedjanitor
--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > Charles Manning wrote: > > >>FWIW, Thumb, and thumb-internetworking, is too much trouble to deal > >>with, I run strictly ARM mode. > >> > >> > > > >To each their own, but I strongly disagree. I use thumb and interworking a > >lot. gcc support for this is great. > > > >I always write all my assembly with interworking (ie using bx) regardless. > > > >For an example you might look at the example stuff I posted on the AT91SAM7 > >group. > > > > > Doing the Internetworking is a new thing for me, newlib and gcc were at > odds with each other over thumb code linking so I removed the ability. > I've got a lot of code to write and plenty of room to work with right > now, perhaps later I will consider moving into Thumb. Yup I agree with your basic strategy. If it ain't broke... :-). The trick to getting interworking right is to use the correct libraries and the correct flags. Some older versions of gcc are a bit broken too. I would not use anything before 3.4.1
2005-11-08 by Dan Beadle
The basic cause of this error is having an program fetch that is not aligned on a multiple of 4. (the 241H in your example). So how did you do this? This can happen by corrupting the stack or altering the stack pointer. (Set the SP to 4000 0241 and do a return will generate the error). The other way is to walk on the stack and alter a return address to point to a non-multiple of 4 and do a return. Yet another way is attempt to do a word or half word load (set rx = 4000 0241, followed by a ldr rm,[rx]). You could do this from assembler, but you can also do it with pointers. Eg. Int *pword; pword = 0x40000241; y = *pword does a fetch from a non-aligned address...) So many opportunities! Dan
-----Original Message----- From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf Of Tom Walsh Sent: Monday, November 07, 2005 5:41 PM To: lpc2000@yahoogroups.com Subject: Re: [lpc2000] Non-aligned access? ee_gary wrote: >Hello, > >I'm having a problem where my code goes into the bushes after ~10 >seconds. Running it in the simulator results in a "Non-aligned >Access" error, ARM Instruction at 00000200H, Memory Access at >40000241H. Any idea what that means? Simple code, just an interrupt >driven timer and interrupt driven SPI... > > > You can run into this when mixing Thumb with ARM code. When interrupt routines are entered, the processor is in ARM mode, either write your handlers in ARM or switch to THUMB mode, process the interrupt, then exit THUMB mode and return from interrupt. FWIW, Thumb, and thumb-internetworking, is too much trouble to deal with, I run strictly ARM mode. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ---------------------------------------------------- Yahoo! Groups Links
2005-11-08 by ee_gary
--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...> wrote:
>
> On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > ee_gary wrote:
> > >Hello,
> > >
> > >I'm having a problem where my code goes into the bushes after ~10
> > >seconds. Running it in the simulator results in a "Non-aligned
> > >Access" error, ARM Instruction at 00000200H, Memory Access at
> > >40000241H. Any idea what that means? Simple code, just an interrupt
> > >driven timer and interrupt driven SPI
> >
>
> What instruction was this accessing?
The instruction at 200H was:
LDR R3,[R1]
It was part of this function:
void wait (void) {
unsigned long i;
i = timeval;
while ((i + 10) != timeval);
}
where 'timeval' is incremented by an ISR.
>
> The following things can give you non-aligned accesses:
>
> 1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
non-2byte
> boundary. This might raise a data abort.
>
> 2) Trying to execute an ARM instruction at a non-4-byte location or
a thumb
> instruction at a non-2-byte location. This might raise a prefetch abort.
>
>
>
> > You can run into this when mixing Thumb with ARM code. When interrupt
> > routines are entered, the processor is in ARM mode, either write your
> > handlers in ARM or switch to THUMB mode, process the interrupt, then
> > exit THUMB mode and return from interrupt.
>
> Yes, this is possible since thumb addresses are marked by setting
the least
> significant bit. If you try executing the address by using a
regular branch
> or bl then this will break. You need to use a bx.
>
> >
> > FWIW, Thumb, and thumb-internetworking, is too much trouble to deal
> > with, I run strictly ARM mode.
>
> To each their own, but I strongly disagree. I use thumb and
interworking a
> lot. gcc support for this is great.
>
> I always write all my assembly with interworking (ie using bx)
regardless.
I'm using all ARM code, with the interworking option enabled in the
compiler/linker.
>
> For an example you might look at the example stuff I posted on the
AT91SAM7
> group.
>2005-11-08 by Guillermo Prandi
Just an idea: perhaps interrupt routines are not saving/restoring all
the registers correctly?
Guille
--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
>
> --- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...>
wrote:
> >
> > On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > > ee_gary wrote:
> > > >Hello,
> > > >
> > > >I'm having a problem where my code goes into the bushes after
~10
> > > >seconds. Running it in the simulator results in a "Non-aligned
> > > >Access" error, ARM Instruction at 00000200H, Memory Access at
> > > >40000241H. Any idea what that means? Simple code, just an
interrupt
> > > >driven timer and interrupt driven SPI
> > >
> >
> > What instruction was this accessing?
>
> The instruction at 200H was:
> LDR R3,[R1]
>
> It was part of this function:
> void wait (void) {
> unsigned long i;
>
> i = timeval;
> while ((i + 10) != timeval);
> }
>
> where 'timeval' is incremented by an ISR.
>
> >
> > The following things can give you non-aligned accesses:
> >
> > 1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
> non-2byte
> > boundary. This might raise a data abort.
> >
> > 2) Trying to execute an ARM instruction at a non-4-byte location
or
> a thumb
> > instruction at a non-2-byte location. This might raise a prefetch
abort.
> >
> >
> >
> > > You can run into this when mixing Thumb with ARM code. When
interrupt
> > > routines are entered, the processor is in ARM mode, either
write your
> > > handlers in ARM or switch to THUMB mode, process the interrupt,
then
> > > exit THUMB mode and return from interrupt.
> >
> > Yes, this is possible since thumb addresses are marked by setting
> the least
> > significant bit. If you try executing the address by using a
> regular branch
> > or bl then this will break. You need to use a bx.
> >
> > >
> > > FWIW, Thumb, and thumb-internetworking, is too much trouble to
deal> > > with, I run strictly ARM mode. > > > > To each their own, but I strongly disagree. I use thumb and > interworking a > > lot. gcc support for this is great. > > > > I always write all my assembly with interworking (ie using bx) > regardless. > > I'm using all ARM code, with the interworking option enabled in the > compiler/linker. > > > > > For an example you might look at the example stuff I posted on the > AT91SAM7 > > group. > > >
2005-11-08 by Charles Manning
On Wednesday 09 November 2005 11:13, Guillermo Prandi wrote: > Just an idea: perhaps interrupt routines are not saving/restoring all > the registers correctly? That would be my first though too. Either that or a stack corruption causing the register to be nuked, but that would probably be less likely. Is 40000241H within the RAM address space? If not, what does it correspond to? If you can figure out how R1 got to have this value you're well on your way to solving the problem.
>
> Guille
>
> --- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
> > --- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...>
>
> wrote:
> > > On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > > > ee_gary wrote:
> > > > >Hello,
> > > > >
> > > > >I'm having a problem where my code goes into the bushes after
>
> ~10
>
> > > > >seconds. Running it in the simulator results in a "Non-aligned
> > > > >Access" error, ARM Instruction at 00000200H, Memory Access at
> > > > >40000241H. Any idea what that means? Simple code, just an
>
> interrupt
>
> > > > >driven timer and interrupt driven SPI
> > >
> > > What instruction was this accessing?
> >
> > The instruction at 200H was:
> > LDR R3,[R1]
> >
> > It was part of this function:
> > void wait (void) {
> > unsigned long i;
> >
> > i = timeval;
> > while ((i + 10) != timeval);
> > }
> >
> > where 'timeval' is incremented by an ISR.
> >
> > > The following things can give you non-aligned accesses:
> > >
> > > 1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
> >
> > non-2byte
> >
> > > boundary. This might raise a data abort.
> > >
> > > 2) Trying to execute an ARM instruction at a non-4-byte location
>
> or
>
> > a thumb
> >
> > > instruction at a non-2-byte location. This might raise a prefetch
>
> abort.
>
> > > > You can run into this when mixing Thumb with ARM code. When
>
> interrupt
>
> > > > routines are entered, the processor is in ARM mode, either
>
> write your
>
> > > > handlers in ARM or switch to THUMB mode, process the interrupt,
>
> then
>
> > > > exit THUMB mode and return from interrupt.
> > >
> > > Yes, this is possible since thumb addresses are marked by setting
> >
> > the least
> >
> > > significant bit. If you try executing the address by using a
> >
> > regular branch
> >
> > > or bl then this will break. You need to use a bx.
> > >
> > > > FWIW, Thumb, and thumb-internetworking, is too much trouble to
>
> deal
>
> > > > with, I run strictly ARM mode.
> > >
> > > To each their own, but I strongly disagree. I use thumb and
> >
> > interworking a
> >
> > > lot. gcc support for this is great.
> > >
> > > I always write all my assembly with interworking (ie using bx)
> >
> > regardless.
> >
> > I'm using all ARM code, with the interworking option enabled in the
> > compiler/linker.
> >
> > > For an example you might look at the example stuff I posted on the
> >
> > AT91SAM7
> >
> > > group.
>
>
>
> Yahoo! Groups Links
>
>
>2005-11-09 by Tom Walsh
Charles Manning wrote:
>On Wednesday 09 November 2005 11:13, Guillermo Prandi wrote:
>
>
>>Just an idea: perhaps interrupt routines are not saving/restoring all
>>the registers correctly?
>>
>>
>
>That would be my first though too.
>
>Either that or a stack corruption causing the register to be nuked, but that
>would probably be less likely.
>
>Is 40000241H within the RAM address space? If not, what does it correspond to?
>
>If you can figure out how R1 got to have this value you're well on your way to
>solving the problem.
>
>
>
>
>
I had that, I grapped some project source of an example program and used
that as the foundation for my project. I got bit by an "__attribute__
((naked))" definition of an ISR handler.
TomW
>
>
>>Guille
>>
>>--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
>>
>>
>>>--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...>
>>>
>>>
>>wrote:
>>
>>
>>>>On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
>>>>
>>>>
>>>>>ee_gary wrote:
>>>>>
>>>>>
>>>>>>Hello,
>>>>>>
>>>>>>I'm having a problem where my code goes into the bushes after
>>>>>>
>>>>>>
>>~10
>>
>>
>>
>>>>>>seconds. Running it in the simulator results in a "Non-aligned
>>>>>>Access" error, ARM Instruction at 00000200H, Memory Access at
>>>>>>40000241H. Any idea what that means? Simple code, just an
>>>>>>
>>>>>>
>>interrupt
>>
>>
>>
>>>>>>driven timer and interrupt driven SPI\ufffd
>>>>>>
>>>>>>
>>>>What instruction was this accessing?
>>>>
>>>>
>>>The instruction at 200H was:
>>>LDR R3,[R1]
>>>
>>>It was part of this function:
>>>void wait (void) {
>>> unsigned long i;
>>>
>>> i = timeval;
>>> while ((i + 10) != timeval);
>>>}
>>>
>>>where 'timeval' is incremented by an ISR.
>>>
>>>
>>>
>>>>The following things can give you non-aligned accesses:
>>>>
>>>>1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
>>>>
>>>>
>>>non-2byte
>>>
>>>
>>>
>>>>boundary. This might raise a data abort.
>>>>
>>>>2) Trying to execute an ARM instruction at a non-4-byte location
>>>>
>>>>
>>or
>>
>>
>>
>>>a thumb
>>>
>>>
>>>
>>>>instruction at a non-2-byte location. This might raise a prefetch
>>>>
>>>>
>>abort.
>>
>>
>>
>>>>>You can run into this when mixing Thumb with ARM code. When
>>>>>
>>>>>
>>interrupt
>>
>>
>>
>>>>>routines are entered, the processor is in ARM mode, either
>>>>>
>>>>>
>>write your
>>
>>
>>
>>>>>handlers in ARM or switch to THUMB mode, process the interrupt,
>>>>>
>>>>>
>>then
>>
>>
>>
>>>>>exit THUMB mode and return from interrupt.
>>>>>
>>>>>
>>>>Yes, this is possible since thumb addresses are marked by setting
>>>>
>>>>
>>>the least
>>>
>>>
>>>
>>>>significant bit. If you try executing the address by using a
>>>>
>>>>
>>>regular branch
>>>
>>>
>>>
>>>>or bl then this will break. You need to use a bx.
>>>>
>>>>
>>>>
>>>>>FWIW, Thumb, and thumb-internetworking, is too much trouble to
>>>>>
>>>>>
>>deal
>>
>>
>>
>>>>>with, I run strictly ARM mode.
>>>>>
>>>>>
>>>>To each their own, but I strongly disagree. I use thumb and
>>>>
>>>>
>>>interworking a
>>>
>>>
>>>
>>>>lot. gcc support for this is great.
>>>>
>>>>I always write all my assembly with interworking (ie using bx)
>>>>
>>>>
>>>regardless.
>>>
>>>I'm using all ARM code, with the interworking option enabled in the
>>>compiler/linker.
>>>
>>>
>>>
>>>>For an example you might look at the example stuff I posted on the
>>>>
>>>>
>>>AT91SAM7
>>>
>>>
>>>
>>>>group.
>>>>
>>>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------2005-11-09 by ee_gary
Definitely seems interrupt related... When I disable the timer interrupt, the interrupt driven spi works great. When I disable the spi interrupt, the interrupt driven timer works great. When both are enabled, I get about 10 seconds of run time and then the program runs off into the bushes. I'm using Keil w/ GCC, ARM-mode. What's special about having two interrupts active that might cause this? Thanks, Gary --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > Charles Manning wrote: > > >On Wednesday 09 November 2005 11:13, Guillermo Prandi wrote: > > > > > >>Just an idea: perhaps interrupt routines are not saving/restoring all > >>the registers correctly? > >> > >> > > > >That would be my first though too. > > > >Either that or a stack corruption causing the register to be nuked, but that > >would probably be less likely. > > > >Is 40000241H within the RAM address space? If not, what does it correspond to? > > > >If you can figure out how R1 got to have this value you're well on your way to > >solving the problem. > > > > > > > > > > > > I had that, I grapped some project source of an example program and used
> that as the foundation for my project. I got bit by an "__attribute__
> ((naked))" definition of an ISR handler.
>
> TomW
>
> >
> >
> >>Guille
> >>
> >>--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
> >>
> >>
> >>>--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...>
> >>>
> >>>
> >>wrote:
> >>
> >>
> >>>>On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> >>>>
> >>>>
> >>>>>ee_gary wrote:
> >>>>>
> >>>>>
> >>>>>>Hello,
> >>>>>>
> >>>>>>I'm having a problem where my code goes into the bushes after
> >>>>>>
> >>>>>>
> >>~10
> >>
> >>
> >>
> >>>>>>seconds. Running it in the simulator results in a "Non-aligned
> >>>>>>Access" error, ARM Instruction at 00000200H, Memory Access at
> >>>>>>40000241H. Any idea what that means? Simple code, just an
> >>>>>>
> >>>>>>
> >>interrupt
> >>
> >>
> >>
> >>>>>>driven timer and interrupt driven SPI
> >>>>>>
> >>>>>>
> >>>>What instruction was this accessing?
> >>>>
> >>>>
> >>>The instruction at 200H was:
> >>>LDR R3,[R1]
> >>>
> >>>It was part of this function:
> >>>void wait (void) {
> >>> unsigned long i;
> >>>
> >>> i = timeval;
> >>> while ((i + 10) != timeval);
> >>>}
> >>>
> >>>where 'timeval' is incremented by an ISR.
> >>>
> >>>
> >>>
> >>>>The following things can give you non-aligned accesses:
> >>>>
> >>>>1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
> >>>>
> >>>>
> >>>non-2byte
> >>>
> >>>
> >>>
> >>>>boundary. This might raise a data abort.
> >>>>
> >>>>2) Trying to execute an ARM instruction at a non-4-byte location
> >>>>
> >>>>
> >>or
> >>
> >>
> >>
> >>>a thumb
> >>>
> >>>
> >>>
> >>>>instruction at a non-2-byte location. This might raise a prefetch
> >>>>
> >>>>
> >>abort.
> >>
> >>
> >>
> >>>>>You can run into this when mixing Thumb with ARM code. When
> >>>>>
> >>>>>
> >>interrupt
> >>
> >>
> >>
> >>>>>routines are entered, the processor is in ARM mode, either
> >>>>>
> >>>>>
> >>write your
> >>
> >>
> >>
> >>>>>handlers in ARM or switch to THUMB mode, process the interrupt,
> >>>>>
> >>>>>
> >>then
> >>
> >>
> >>
> >>>>>exit THUMB mode and return from interrupt.
> >>>>>
> >>>>>
> >>>>Yes, this is possible since thumb addresses are marked by setting
> >>>>
> >>>>
> >>>the least
> >>>
> >>>
> >>>
> >>>>significant bit. If you try executing the address by using a
> >>>>
> >>>>
> >>>regular branch
> >>>
> >>>
> >>>
> >>>>or bl then this will break. You need to use a bx.
> >>>>
> >>>>
> >>>>
> >>>>>FWIW, Thumb, and thumb-internetworking, is too much trouble to
> >>>>>
> >>>>>
> >>deal
> >>
> >>
> >>
> >>>>>with, I run strictly ARM mode.
> >>>>>
> >>>>>
> >>>>To each their own, but I strongly disagree. I use thumb and
> >>>>
> >>>>
> >>>interworking a
> >>>
> >>>
> >>>
> >>>>lot. gcc support for this is great.
> >>>>
> >>>>I always write all my assembly with interworking (ie using bx)
> >>>>
> >>>>
> >>>regardless.
> >>>
> >>>I'm using all ARM code, with the interworking option enabled in the
> >>>compiler/linker.
> >>>
> >>>
> >>>
> >>>>For an example you might look at the example stuff I posted on the
> >>>>
> >>>>
> >>>AT91SAM7
> >>>
> >>>
> >>>
> >>>>group.
> >>>>
> >>>>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>2005-11-09 by rtstofer
--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote: > > Definitely seems interrupt related... When I disable the timer > interrupt, the interrupt driven spi works great. When I disable the > spi interrupt, the interrupt driven timer works great. When both are > enabled, I get about 10 seconds of run time and then the program runs > off into the bushes. I'm using Keil w/ GCC, ARM-mode. What's > special about having two interrupts active that might cause this? > > Thanks, > > Gary Maybe the stack size? Richard
2005-11-09 by Charles Manning
On Wednesday 09 November 2005 14:03, ee_gary wrote:
> Definitely seems interrupt related... When I disable the timer
> interrupt, the interrupt driven spi works great. When I disable the
> spi interrupt, the interrupt driven timer works great. When both are
> enabled, I get about 10 seconds of run time and then the program runs
> off into the bushes. I'm using Keil w/ GCC, ARM-mode. What's
> special about having two interrupts active that might cause this?
How are you processing interrupts? Perhaps posting your wrapper code (ie the
assembler calling the C ISRs).
There are two things that I can see causing problems here:
1) If you are reenabling interrupts during the ISR then you can get stack
overflows or the second ISR starting processing before the isr is completely
done.
2) If you have not allowed enough stack for the ISR then stack mashing can be
bad for you.
I suggest doing non-nested interrupt handling first.
Here's what I do for a SAM7, the Philips should be identical except maybe for
IVR acknowledgment.
The C functions are regular C functions with no attributes.
@
@ IRQ wrappers.
@
@ These call a C function.
@ We switch to supervisor mode and reenable interrupts to allow nesting.
@
@
.text
.code 32
.align 2
@
@ Macros
@
.macro irq_wrapper_nested, C_function
@ Save registers on stack
sub r14,r14,#4 @ fix up for return
stmfd r13!,{r14}
mrs r14,spsr
stmfd r13!,{r14}
@ Acknowledge the IVR for debugging to support Protected Mode
ldr r14,=0xFFFFF100
str r14,[r14]
@ swich to system mode and enable IRQ, but not FIQ
msr cpsr_c,#0x5F
@push stack
stmfd r13!,{r0-r12,r14}
@ Call the function
ldr r0,=\C_function
mov lr,pc
bx r0
@ pop stack
ldmfd r13!,{r0-r12,r14}
@ swich to interrupt mode and disable IRQs and FIQs
msr cpsr_c,#0xD2
@End of interrupt by doing a write to AIC_EOICR
ldr r14,=0xFFFFF130
str r14,[r14]
@ Unstack the saved spsr
ldmfd r13!,{r14}
msr spsr_all,r14
@ Return from interrupt (unstacking the modified r14)
ldmfd r13!,{pc}^
.endm
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
.macro irq_wrapper_not_nested, C_function
@ Save registers on stack
sub r14,r14,#4 @ fix up for return
stmfd r13!,{r0-r3,r14}
@ Acknowledge the IVR for debugging to support Protected Mode
ldr r14,=0xFFFFF100
str r14,[r14]
@ Call the function
ldr r0,=\C_function
mov lr,pc
bx r0
@End of interrupt by doing a write to AIC_EOICR
ldr r14,=0xFFFFF130
str r14,[r0]
@ Return from interrupt (unstacking the modified r14)
ldmfd r13!,{r0-r3,12,pc}^
.endm
@
@ ISRs
@
@
.global spurious_isr
.global default_isr
.global default_fiq
default_fiq:
spurious_isr:
default_isr:
b default_isr
.extern systick_isr_C
.global systick_isr_entry
systick_isr_entry:
irq_wrapper_nested systick_isr_C
.extern udp_isr_C
.global udp_isr_entry
udp_isr_entry:
irq_wrapper_nested udp_isr_C
.extern uart_isr_C_0
.global uart_isr_entry_0
uart_isr_entry_0:
irq_wrapper_nested uart_isr_C_0
.extern uart_isr_C_1
.global uart_isr_entry_1
uart_isr_entry_1:
irq_wrapper_nested uart_isr_C_1>
> Thanks,
>
> Gary
>
> --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> > Charles Manning wrote:
> > >On Wednesday 09 November 2005 11:13, Guillermo Prandi wrote:
> > >>Just an idea: perhaps interrupt routines are not saving/restoring all
> > >>the registers correctly?
> > >
> > >That would be my first though too.
> > >
> > >Either that or a stack corruption causing the register to be nuked,
>
> but that
>
> > >would probably be less likely.
> > >
> > >Is 40000241H within the RAM address space? If not, what does it
>
> correspond to?
>
> > >If you can figure out how R1 got to have this value you're well on
>
> your way to
>
> > >solving the problem.
> >
> > I had that, I grapped some project source of an example program and
>
> used
>
> > that as the foundation for my project. I got bit by an "__attribute__
> > ((naked))" definition of an ISR handler.
> >
> > TomW
> >
> > >>Guille
> > >>
> > >>--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
> > >>>--- In lpc2000@yahoogroups.com, Charles Manning <manningc2@a...>
> > >>
> > >>wrote:
> > >>>>On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > >>>>>ee_gary wrote:
> > >>>>>>Hello,
> > >>>>>>
> > >>>>>>I'm having a problem where my code goes into the bushes after
> > >>
> > >>~10
> > >>
> > >>>>>>seconds. Running it in the simulator results in a "Non-aligned
> > >>>>>>Access" error, ARM Instruction at 00000200H, Memory Access at
> > >>>>>>40000241H. Any idea what that means? Simple code, just an
> > >>
> > >>interrupt
> > >>
> > >>>>>>driven timer and interrupt driven SPI
> > >>>>
> > >>>>What instruction was this accessing?
> > >>>
> > >>>The instruction at 200H was:
> > >>>LDR R3,[R1]
> > >>>
> > >>>It was part of this function:
> > >>>void wait (void) {
> > >>> unsigned long i;
> > >>>
> > >>> i = timeval;
> > >>> while ((i + 10) != timeval);
> > >>>}
> > >>>
> > >>>where 'timeval' is incremented by an ISR.
> > >>>
> > >>>>The following things can give you non-aligned accesses:
> > >>>>
> > >>>>1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
> > >>>
> > >>>non-2byte
> > >>>
> > >>>>boundary. This might raise a data abort.
> > >>>>
> > >>>>2) Trying to execute an ARM instruction at a non-4-byte location
> > >>
> > >>or
> > >>
> > >>>a thumb
> > >>>
> > >>>>instruction at a non-2-byte location. This might raise a prefetch
> > >>
> > >>abort.
> > >>
> > >>>>>You can run into this when mixing Thumb with ARM code. When
> > >>
> > >>interrupt
> > >>
> > >>>>>routines are entered, the processor is in ARM mode, either
> > >>
> > >>write your
> > >>
> > >>>>>handlers in ARM or switch to THUMB mode, process the interrupt,
> > >>
> > >>then
> > >>
> > >>>>>exit THUMB mode and return from interrupt.
> > >>>>
> > >>>>Yes, this is possible since thumb addresses are marked by setting
> > >>>
> > >>>the least
> > >>>
> > >>>>significant bit. If you try executing the address by using a
> > >>>
> > >>>regular branch
> > >>>
> > >>>>or bl then this will break. You need to use a bx.
> > >>>>
> > >>>>>FWIW, Thumb, and thumb-internetworking, is too much trouble to
> > >>
> > >>deal
> > >>
> > >>>>>with, I run strictly ARM mode.
> > >>>>
> > >>>>To each their own, but I strongly disagree. I use thumb and
> > >>>
> > >>>interworking a
> > >>>
> > >>>>lot. gcc support for this is great.
> > >>>>
> > >>>>I always write all my assembly with interworking (ie using bx)
> > >>>
> > >>>regardless.
> > >>>
> > >>>I'm using all ARM code, with the interworking option enabled in the
> > >>>compiler/linker.
> > >>>
> > >>>>For an example you might look at the example stuff I posted on the
> > >>>
> > >>>AT91SAM7
> > >>>
> > >>>>group.
> > >>
> > >>Yahoo! Groups Links
> > >
> > >Yahoo! Groups Links
> >
> > --
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware.net, http://cyberiansoftware.com
> > "Windows? No thanks, I have work to do..."
> > ----------------------------------------------------
>
>
>
> Yahoo! Groups Links
>
>
>2006-01-21 by Guillermo Prandi
Gary, I wonder if you could solve your problem. I am facing the same
problem here too. :(
Guille
--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
>
> Definitely seems interrupt related... When I disable the timer
> interrupt, the interrupt driven spi works great. When I disable the
> spi interrupt, the interrupt driven timer works great. When both
are
> enabled, I get about 10 seconds of run time and then the program
runs
> off into the bushes. I'm using Keil w/ GCC, ARM-mode. What's
> special about having two interrupts active that might cause this?
>
> Thanks,
>
> Gary
>
> --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> >
> > Charles Manning wrote:
> >
> > >On Wednesday 09 November 2005 11:13, Guillermo Prandi wrote:
> > >
> > >
> > >>Just an idea: perhaps interrupt routines are not
saving/restoring all
> > >>the registers correctly?
> > >>
> > >>
> > >
> > >That would be my first though too.
> > >
> > >Either that or a stack corruption causing the register to be
nuked,
> but that
> > >would probably be less likely.
> > >
> > >Is 40000241H within the RAM address space? If not, what does it
> correspond to?
> > >
> > >If you can figure out how R1 got to have this value you're well
on
> your way to
> > >solving the problem.
> > >
> > >
> > >
> > >
> > >
> >
> > I had that, I grapped some project source of an example program
and
> used
> > that as the foundation for my project. I got bit by
an "__attribute__
> > ((naked))" definition of an ISR handler.
> >
> > TomW
> >
> > >
> > >
> > >>Guille
> > >>
> > >>--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
> > >>
> > >>
> > >>>--- In lpc2000@yahoogroups.com, Charles Manning
<manningc2@a...>
> > >>>
> > >>>
> > >>wrote:
> > >>
> > >>
> > >>>>On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > >>>>
> > >>>>
> > >>>>>ee_gary wrote:
> > >>>>>
> > >>>>>
> > >>>>>>Hello,
> > >>>>>>
> > >>>>>>I'm having a problem where my code goes into the bushes
after
> > >>>>>>
> > >>>>>>
> > >>~10
> > >>
> > >>
> > >>
> > >>>>>>seconds. Running it in the simulator results in a "Non-
aligned
> > >>>>>>Access" error, ARM Instruction at 00000200H, Memory Access
at
> > >>>>>>40000241H. Any idea what that means? Simple code, just an
> > >>>>>>
> > >>>>>>
> > >>interrupt
> > >>
> > >>
> > >>
> > >>>>>>driven timer and interrupt driven SPI
> > >>>>>>
> > >>>>>>
> > >>>>What instruction was this accessing?
> > >>>>
> > >>>>
> > >>>The instruction at 200H was:
> > >>>LDR R3,[R1]
> > >>>
> > >>>It was part of this function:
> > >>>void wait (void) {
> > >>> unsigned long i;
> > >>>
> > >>> i = timeval;
> > >>> while ((i + 10) != timeval);
> > >>>}
> > >>>
> > >>>where 'timeval' is incremented by an ISR.
> > >>>
> > >>>
> > >>>
> > >>>>The following things can give you non-aligned accesses:
> > >>>>
> > >>>>1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
> > >>>>
> > >>>>
> > >>>non-2byte
> > >>>
> > >>>
> > >>>
> > >>>>boundary. This might raise a data abort.
> > >>>>
> > >>>>2) Trying to execute an ARM instruction at a non-4-byte
location
> > >>>>
> > >>>>
> > >>or
> > >>
> > >>
> > >>
> > >>>a thumb
> > >>>
> > >>>
> > >>>
> > >>>>instruction at a non-2-byte location. This might raise a
prefetch
> > >>>>
> > >>>>
> > >>abort.
> > >>
> > >>
> > >>
> > >>>>>You can run into this when mixing Thumb with ARM code. When
> > >>>>>
> > >>>>>
> > >>interrupt
> > >>
> > >>
> > >>
> > >>>>>routines are entered, the processor is in ARM mode, either
> > >>>>>
> > >>>>>
> > >>write your
> > >>
> > >>
> > >>
> > >>>>>handlers in ARM or switch to THUMB mode, process the
interrupt,
> > >>>>>
> > >>>>>
> > >>then
> > >>
> > >>
> > >>
> > >>>>>exit THUMB mode and return from interrupt.
> > >>>>>
> > >>>>>
> > >>>>Yes, this is possible since thumb addresses are marked by
setting
> > >>>>
> > >>>>
> > >>>the least
> > >>>
> > >>>
> > >>>
> > >>>>significant bit. If you try executing the address by using a
> > >>>>
> > >>>>
> > >>>regular branch
> > >>>
> > >>>
> > >>>
> > >>>>or bl then this will break. You need to use a bx.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>FWIW, Thumb, and thumb-internetworking, is too much trouble
to
> > >>>>>
> > >>>>>
> > >>deal
> > >>
> > >>
> > >>
> > >>>>>with, I run strictly ARM mode.
> > >>>>>
> > >>>>>
> > >>>>To each their own, but I strongly disagree. I use thumb and
> > >>>>
> > >>>>
> > >>>interworking a
> > >>>
> > >>>
> > >>>
> > >>>>lot. gcc support for this is great.
> > >>>>
> > >>>>I always write all my assembly with interworking (ie using bx)
> > >>>>
> > >>>>
> > >>>regardless.
> > >>>
> > >>>I'm using all ARM code, with the interworking option enabled
in the
> > >>>compiler/linker.
> > >>>
> > >>>
> > >>>
> > >>>>For an example you might look at the example stuff I posted
on the> > >>>> > > >>>> > > >>>AT91SAM7 > > >>> > > >>> > > >>> > > >>>>group. > > >>>> > > >>>> > > >> > > >>Yahoo! Groups Links > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > >Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Tom Walsh - WN3L - Embedded Systems Consultant > > http://openhardware.net, http://cyberiansoftware.com > > "Windows? No thanks, I have work to do..." > > ---------------------------------------------------- > > >
2006-01-22 by Daniel Gelbgras
Hi, My guess is that you may want to increase the (normal) interrupt stack *size* and FIQ interrupt stack *size* in your cpu startup (initialization) file For example in Keil startup.s file, these constants are IRQ_Stack_Size and USR_Stack_Size (When you use only a single interrupt, either FIQ or normal interrupt, it is working because there is some allocated stack space, but I suppose that one of these 2 constants is too small, so you use the same memory space for both isr's If you enable both interrupts together, one isr can corrupt the register values saved by the other isr, and the program crashes after a variable amount of time) HTH kind regards daniel
----- Original Message -----
From: Guillermo Prandi
To: lpc2000@yahoogroups.com
Sent: Saturday, January 21, 2006 10:34 PM
Subject: [lpc2000] Re: Non-aligned access?
Gary, I wonder if you could solve your problem. I am facing the same
problem here too. :(
Guille
--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
>
> Definitely seems interrupt related... When I disable the timer
> interrupt, the interrupt driven spi works great. When I disable the
> spi interrupt, the interrupt driven timer works great. When both
are
> enabled, I get about 10 seconds of run time and then the program
runs
> off into the bushes. I'm using Keil w/ GCC, ARM-mode. What's
> special about having two interrupts active that might cause this?
>
> Thanks,
>
> Gary
>
> --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> >
> > Charles Manning wrote:
> >
> > >On Wednesday 09 November 2005 11:13, Guillermo Prandi wrote:
> > >
> > >
> > >>Just an idea: perhaps interrupt routines are not
saving/restoring all
> > >>the registers correctly?
> > >>
> > >>
> > >
> > >That would be my first though too.
> > >
> > >Either that or a stack corruption causing the register to be
nuked,
> but that
> > >would probably be less likely.
> > >
> > >Is 40000241H within the RAM address space? If not, what does it
> correspond to?
> > >
> > >If you can figure out how R1 got to have this value you're well
on
> your way to
> > >solving the problem.
> > >
> > >
> > >
> > >
> > >
> >
> > I had that, I grapped some project source of an example program
and
> used
> > that as the foundation for my project. I got bit by
an "__attribute__
> > ((naked))" definition of an ISR handler.
> >
> > TomW
> >
> > >
> > >
> > >>Guille
> > >>
> > >>--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
> > >>
> > >>
> > >>>--- In lpc2000@yahoogroups.com, Charles Manning
<manningc2@a...>
> > >>>
> > >>>
> > >>wrote:
> > >>
> > >>
> > >>>>On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > >>>>
> > >>>>
> > >>>>>ee_gary wrote:
> > >>>>>
> > >>>>>
> > >>>>>>Hello,
> > >>>>>>
> > >>>>>>I'm having a problem where my code goes into the bushes
after
> > >>>>>>
> > >>>>>>
> > >>~10
> > >>
> > >>
> > >>
> > >>>>>>seconds. Running it in the simulator results in a "Non-
aligned
> > >>>>>>Access" error, ARM Instruction at 00000200H, Memory Access
at
> > >>>>>>40000241H. Any idea what that means? Simple code, just an
> > >>>>>>
> > >>>>>>
> > >>interrupt
> > >>
> > >>
> > >>
> > >>>>>>driven timer and interrupt driven SPI.
> > >>>>>>
> > >>>>>>
> > >>>>What instruction was this accessing?
> > >>>>
> > >>>>
> > >>>The instruction at 200H was:
> > >>>LDR R3,[R1]
> > >>>
> > >>>It was part of this function:
> > >>>void wait (void) {
> > >>> unsigned long i;
> > >>>
> > >>> i = timeval;
> > >>> while ((i + 10) != timeval);
> > >>>}
> > >>>
> > >>>where 'timeval' is incremented by an ISR.
> > >>>
> > >>>
> > >>>
> > >>>>The following things can give you non-aligned accesses:
> > >>>>
> > >>>>1) Trying to read a U32 on a non-4-byte boundary or a U16 on a
> > >>>>
> > >>>>
> > >>>non-2byte
> > >>>
> > >>>
> > >>>
> > >>>>boundary. This might raise a data abort.
> > >>>>
> > >>>>2) Trying to execute an ARM instruction at a non-4-byte
location
> > >>>>
> > >>>>
> > >>or
> > >>
> > >>
> > >>
> > >>>a thumb
> > >>>
> > >>>
> > >>>
> > >>>>instruction at a non-2-byte location. This might raise a
prefetch
> > >>>>
> > >>>>
> > >>abort.
> > >>
> > >>
> > >>
> > >>>>>You can run into this when mixing Thumb with ARM code. When
> > >>>>>
> > >>>>>
> > >>interrupt
> > >>
> > >>
> > >>
> > >>>>>routines are entered, the processor is in ARM mode, either
> > >>>>>
> > >>>>>
> > >>write your
> > >>
> > >>
> > >>
> > >>>>>handlers in ARM or switch to THUMB mode, process the
interrupt,
> > >>>>>
> > >>>>>
> > >>then
> > >>
> > >>
> > >>
> > >>>>>exit THUMB mode and return from interrupt.
> > >>>>>
> > >>>>>
> > >>>>Yes, this is possible since thumb addresses are marked by
setting
> > >>>>
> > >>>>
> > >>>the least
> > >>>
> > >>>
> > >>>
> > >>>>significant bit. If you try executing the address by using a
> > >>>>
> > >>>>
> > >>>regular branch
> > >>>
> > >>>
> > >>>
> > >>>>or bl then this will break. You need to use a bx.
> > >>>>
> > >>>>
> > >>>>
> > >>>>>FWIW, Thumb, and thumb-internetworking, is too much trouble
to
> > >>>>>
> > >>>>>
> > >>deal
> > >>
> > >>
> > >>
> > >>>>>with, I run strictly ARM mode.
> > >>>>>
> > >>>>>
> > >>>>To each their own, but I strongly disagree. I use thumb and
> > >>>>
> > >>>>
> > >>>interworking a
> > >>>
> > >>>
> > >>>
> > >>>>lot. gcc support for this is great.
> > >>>>
> > >>>>I always write all my assembly with interworking (ie using bx)
> > >>>>
> > >>>>
> > >>>regardless.
> > >>>
> > >>>I'm using all ARM code, with the interworking option enabled
in the
> > >>>compiler/linker.
> > >>>
> > >>>
> > >>>
> > >>>>For an example you might look at the example stuff I posted
on the
> > >>>>
> > >>>>
> > >>>AT91SAM7
> > >>>
> > >>>
> > >>>
> > >>>>group.
> > >>>>
> > >>>>
> > >>
> > >>Yahoo! Groups Links
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Tom Walsh - WN3L - Embedded Systems Consultant
> > http://openhardware.net, http://cyberiansoftware.com
> > "Windows? No thanks, I have work to do..."
> > ----------------------------------------------------
> >
>
SPONSORED LINKS Microcontrollers Microprocessor Intel microprocessors
Pic microcontrollers
------------------------------------------------------------------------------
YAHOO! GROUPS LINKS
a.. Visit your group "lpc2000" on the web.
b.. To unsubscribe from this group, send an email to:
lpc2000-unsubscribe@yahoogroups.com
c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------------------------------------------------------------------------------
[Non-text portions of this message have been removed]2006-01-22 by Guillermo Prandi
Thanks, Daniel. In my case I am not using nested interrupts, and my
stacks are pretty generous (LPC2138=32K RAM). That's why I am
puzzled. I am using FreeRTOS/GCC4.0.1. This is an excerpt of my
startup code:
--------------------------------------------------
// Stack Sizes
.set UND_STACK_SIZE, 0x00000040
.set ABT_STACK_SIZE, 0x00000040
.set FIQ_STACK_SIZE, 0x00000040
.set IRQ_STACK_SIZE, 0x00000400
.set SVC_STACK_SIZE, 0x00000400
// Initialize Interrupt System
// - Set stack location for each mode
// - Leave in Supervisor Mode with Interrupts Disabled
// -----------------------------------------------
ldr r0,=_stack // 0x40008000 minus 32 bytes for IAP.
msr CPSR_c,#MODE_UND|I_BIT|F_BIT
mov sp,r0
sub r0,r0,#UND_STACK_SIZE
msr CPSR_c,#MODE_ABT|I_BIT|F_BIT
mov sp,r0
sub r0,r0,#ABT_STACK_SIZE
msr CPSR_c,#MODE_FIQ|I_BIT|F_BIT
mov sp,r0
sub r0,r0,#FIQ_STACK_SIZE
msr CPSR_c,#MODE_IRQ|I_BIT
mov sp,r0
sub r0,r0,#IRQ_STACK_SIZE
msr CPSR_c,#MODE_SVC|I_BIT|F_BIT
mov sp,r0
sub r0,r0,#SVC_STACK_SIZE
msr CPSR_c,#MODE_SYS|I_BIT|F_BIT
mov sp,r0
// (This is from FreeRTOS)
// We want to start in supervisor mode.
// Operation will switch to system
// mode when the first task starts.
msr CPSR_c,#MODE_SVC|I_BIT|F_BIT
// Initialization and startup follows
....
--------------------------------------------------
FIQs are not a concern; I use them as a "specialized" reset button
via EINT3 (it does little more than reset). They are not normally
triggered.
I even added a check before each interrupt routine. Check it out:
#define INTERRUPT_CHECK \
{ register int _sp asm("sp"); \
asm volatile ("mov r0,#0x40000000" ); \
asm volatile ("orr r0,r0,#0x000000e0" ); \
asm volatile ("orr r0,r0,#0x00007f00" ); \
asm volatile ("cmp r0,sp" ); \
asm volatile ("blo 0f" ); \
asm volatile ("sub r0,r0,#0x00000100" ); \
asm volatile ("cmp r0,sp" ); \
asm volatile ("blo 1f" ); \
asm volatile ("0:" ); \
error_n1("OUT OF STACK!",_sp); \
asm volatile ("1:" ); \
}
void MyFunc(void) __attribute__ ((interrupt("IRQ")));
void MyFunc(void)
{
INTERRUPT_CHECK
/* my code here */
}
The IRQ stack should be below 0x40007fe0 and is 512 bytes long. The
error function enters a safe-mode (IRQs disabled, initializes
hardware, outputs given string or "bad pointer" if problems with the
string). The error_n1() function has been tested several times in
other circumstances and it works like a charm (for instance, it is
called from the pabt, dabt and undf handlers which DO trigger!).
The stack check from above never fires (except when I tamper with the
values just to verify that it WOULD trigger). On the other hand, I
keep getting undf, dabt and pabt everywhere (i.e., r15 pointing to
RAM or some weird location) when I start using any SPI interrupt
routine. I rewritten my program several times, tried many ways, but
every time the SPI interrupt service routine starts executing, I get
a crash sooner or later (within 10 seconds is a good average). This
doesn't happen with my other interrupt routines, like my two UARTs or
the OS timer tick. They work fine. I just don't know what to check
next. Sometimes the problem doesn't show up for hours if I compile
with no optimization (-O0) and sometimes it seems to work a little
longer if I set the processor to run at 10x5 MHz (I usually run it at
10x1 MHz). The system crashed with IRQ routines as simple as this:
static void dummySPIIRQ(void) __attribute__ ((interrupt("IRQ")));
static void dummySPIIRQ(void)
{
tdSPI++;
if( S0SPSR & S0SPSR_SPIF )
{
IOSET0 = PIN7BIT; // Remove /CS from target SPI device
short rddata = S0SPDR;
tdSPIRDY = (0xffff & (int) rddata) | 0x80000000;
}
S0SPINT = 0x01;
VICVectAddr = 0x00000000;
}
To worsen things even more, I don't have a JTAG connector on my
board. Any suggestions will be greately appreciated.
Guille
--- In lpc2000@yahoogroups.com, "Daniel Gelbgras"
<daniel.gelbgras@e...> wrote:
>
> Hi,
>
> My guess is that you may want to increase
> the (normal) interrupt stack *size*
> and FIQ interrupt stack *size*
> in your cpu startup (initialization) file
>
> For example in Keil startup.s file, these constants are
> IRQ_Stack_Size and USR_Stack_Size
>
>
> (When you use only a single interrupt, either FIQ or normal
interrupt,
> it is working because there is some allocated stack space,
> but I suppose that one of these 2 constants is too small,
> so you use the same memory space for both isr's
>
> If you enable both interrupts together,
> one isr can corrupt the register values saved by the other
isr,
> and the program crashes after a variable amount of time)
>
> HTH
> kind regards
> daniel
> ----- Original Message -----
> From: Guillermo Prandi
> To: lpc2000@yahoogroups.com
> Sent: Saturday, January 21, 2006 10:34 PM
> Subject: [lpc2000] Re: Non-aligned access?
>
>
> Gary, I wonder if you could solve your problem. I am facing the
same
> problem here too. :(
>
> Guille
>
> --- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
> >
> > Definitely seems interrupt related... When I disable the timer
> > interrupt, the interrupt driven spi works great. When I
disable the
> > spi interrupt, the interrupt driven timer works great. When
both
> are
> > enabled, I get about 10 seconds of run time and then the
program
> runs
> > off into the bushes. I'm using Keil w/ GCC, ARM-mode. What's
> > special about having two interrupts active that might cause
this?
> >
> > Thanks,
> >
> > Gary
> >
> > --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> > >
> > > Charles Manning wrote:
> > >
> > > >On Wednesday 09 November 2005 11:13, Guillermo Prandi wrote:
> > > >
> > > >
> > > >>Just an idea: perhaps interrupt routines are not
> saving/restoring all
> > > >>the registers correctly?
> > > >>
> > > >>
> > > >
> > > >That would be my first though too.
> > > >
> > > >Either that or a stack corruption causing the register to be
> nuked,
> > but that
> > > >would probably be less likely.
> > > >
> > > >Is 40000241H within the RAM address space? If not, what does
it
> > correspond to?
> > > >
> > > >If you can figure out how R1 got to have this value you're
well
> on
> > your way to
> > > >solving the problem.
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > I had that, I grapped some project source of an example
program
> and
> > used
> > > that as the foundation for my project. I got bit by
> an "__attribute__
> > > ((naked))" definition of an ISR handler.
> > >
> > > TomW
> > >
> > > >
> > > >
> > > >>Guille
> > > >>
> > > >>--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...>
wrote:
> > > >>
> > > >>
> > > >>>--- In lpc2000@yahoogroups.com, Charles Manning
> <manningc2@a...>
> > > >>>
> > > >>>
> > > >>wrote:
> > > >>
> > > >>
> > > >>>>On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > > >>>>
> > > >>>>
> > > >>>>>ee_gary wrote:
> > > >>>>>
> > > >>>>>
> > > >>>>>>Hello,
> > > >>>>>>
> > > >>>>>>I'm having a problem where my code goes into the bushes
> after
> > > >>>>>>
> > > >>>>>>
> > > >>~10
> > > >>
> > > >>
> > > >>
> > > >>>>>>seconds. Running it in the simulator results in a "Non-
> aligned
> > > >>>>>>Access" error, ARM Instruction at 00000200H, Memory
Access
> at
> > > >>>>>>40000241H. Any idea what that means? Simple code,
just an
> > > >>>>>>
> > > >>>>>>
> > > >>interrupt
> > > >>
> > > >>
> > > >>
> > > >>>>>>driven timer and interrupt driven SPI.
> > > >>>>>>
> > > >>>>>>
> > > >>>>What instruction was this accessing?
> > > >>>>
> > > >>>>
> > > >>>The instruction at 200H was:
> > > >>>LDR R3,[R1]
> > > >>>
> > > >>>It was part of this function:
> > > >>>void wait (void) {
> > > >>> unsigned long i;
> > > >>>
> > > >>> i = timeval;
> > > >>> while ((i + 10) != timeval);
> > > >>>}
> > > >>>
> > > >>>where 'timeval' is incremented by an ISR.
> > > >>>
> > > >>>
> > > >>>
> > > >>>>The following things can give you non-aligned accesses:
> > > >>>>
> > > >>>>1) Trying to read a U32 on a non-4-byte boundary or a U16
on a
> > > >>>>
> > > >>>>
> > > >>>non-2byte
> > > >>>
> > > >>>
> > > >>>
> > > >>>>boundary. This might raise a data abort.
> > > >>>>
> > > >>>>2) Trying to execute an ARM instruction at a non-4-byte
> location
> > > >>>>
> > > >>>>
> > > >>or
> > > >>
> > > >>
> > > >>
> > > >>>a thumb
> > > >>>
> > > >>>
> > > >>>
> > > >>>>instruction at a non-2-byte location. This might raise a
> prefetch
> > > >>>>
> > > >>>>
> > > >>abort.
> > > >>
> > > >>
> > > >>
> > > >>>>>You can run into this when mixing Thumb with ARM code.
When
> > > >>>>>
> > > >>>>>
> > > >>interrupt
> > > >>
> > > >>
> > > >>
> > > >>>>>routines are entered, the processor is in ARM mode,
either
> > > >>>>>
> > > >>>>>
> > > >>write your
> > > >>
> > > >>
> > > >>
> > > >>>>>handlers in ARM or switch to THUMB mode, process the
> interrupt,
> > > >>>>>
> > > >>>>>
> > > >>then
> > > >>
> > > >>
> > > >>
> > > >>>>>exit THUMB mode and return from interrupt.
> > > >>>>>
> > > >>>>>
> > > >>>>Yes, this is possible since thumb addresses are marked by
> setting
> > > >>>>
> > > >>>>
> > > >>>the least
> > > >>>
> > > >>>
> > > >>>
> > > >>>>significant bit. If you try executing the address by
using a
> > > >>>>
> > > >>>>
> > > >>>regular branch
> > > >>>
> > > >>>
> > > >>>
> > > >>>>or bl then this will break. You need to use a bx.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>FWIW, Thumb, and thumb-internetworking, is too much
trouble
> to
> > > >>>>>
> > > >>>>>
> > > >>deal
> > > >>
> > > >>
> > > >>
> > > >>>>>with, I run strictly ARM mode.
> > > >>>>>
> > > >>>>>
> > > >>>>To each their own, but I strongly disagree. I use thumb
and
> > > >>>>
> > > >>>>
> > > >>>interworking a
> > > >>>
> > > >>>
> > > >>>
> > > >>>>lot. gcc support for this is great.
> > > >>>>
> > > >>>>I always write all my assembly with interworking (ie
using bx)
> > > >>>>
> > > >>>>
> > > >>>regardless.
> > > >>>
> > > >>>I'm using all ARM code, with the interworking option
enabled
> in the
> > > >>>compiler/linker.
> > > >>>
> > > >>>
> > > >>>
> > > >>>>For an example you might look at the example stuff I
posted
> on the
> > > >>>>
> > > >>>>
> > > >>>AT91SAM7
> > > >>>
> > > >>>
> > > >>>
> > > >>>>group.
> > > >>>>
> > > >>>>
> > > >>
> > > >>Yahoo! Groups Links
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Tom Walsh - WN3L - Embedded Systems Consultant
> > > http://openhardware.net, http://cyberiansoftware.com
> > > "Windows? No thanks, I have work to do..."
> > > ----------------------------------------------------
> > >
> >
>
>
>
>
>
>
> SPONSORED LINKS Microcontrollers Microprocessor Intel
microprocessors
> Pic microcontrollers
>
>
> --------------------------------------------------------------------
----------
> YAHOO! GROUPS LINKS
>
> a.. Visit your group "lpc2000" on the web.
>
> b.. To unsubscribe from this group, send an email to:
> lpc2000-unsubscribe@yahoogroups.com
>
> c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
of Service.
>
>
> --------------------------------------------------------------------
----------> > > > [Non-text portions of this message have been removed] >
2006-01-25 by Guillermo Prandi
OK, mine was a mewbie mistake. I FORGOT TO READ the FreeRTOS LPC2xxx
port notes, and therefore I missed the importance of starting/ending
every ISR function that might perform a task switch (e.g., via
xQueueSendFromISR) with the portENTER_SWITCHING_ISR() /
portEXIT_SWITCHING_ISR() pair of macros. I also started my project
from a WinARM demo example instead of a FreeRTOS example. Shame on me.
On the other hand, someone might find interesting that after
correcting this I bumped into this bug in the FreeRTOS LPC2106 GCC
port that seems to show up *sometimes* with GCC 4.01. There's already
a patch available and it will be fixed in the next release of
FreeRTOS. Read the thread here:
http://sourceforge.net/forum/message.php?msg_id=3537580
Guille
--- In lpc2000@yahoogroups.com, "Guillermo Prandi"
<yahoo.messenger@m...> wrote:
>
> Thanks, Daniel. In my case I am not using nested interrupts, and my
> stacks are pretty generous (LPC2138=32K RAM). That's why I am
> puzzled. I am using FreeRTOS/GCC4.0.1. This is an excerpt of my
> startup code:
>
> --------------------------------------------------
> // Stack Sizes
> .set UND_STACK_SIZE, 0x00000040
> .set ABT_STACK_SIZE, 0x00000040
> .set FIQ_STACK_SIZE, 0x00000040
> .set IRQ_STACK_SIZE, 0x00000400
> .set SVC_STACK_SIZE, 0x00000400
>
> // Initialize Interrupt System
> // - Set stack location for each mode
> // - Leave in Supervisor Mode with Interrupts Disabled
> // -----------------------------------------------
> ldr r0,=_stack // 0x40008000 minus 32 bytes for IAP.
> msr CPSR_c,#MODE_UND|I_BIT|F_BIT
> mov sp,r0
> sub r0,r0,#UND_STACK_SIZE
>
> msr CPSR_c,#MODE_ABT|I_BIT|F_BIT
> mov sp,r0
> sub r0,r0,#ABT_STACK_SIZE
>
> msr CPSR_c,#MODE_FIQ|I_BIT|F_BIT
> mov sp,r0
> sub r0,r0,#FIQ_STACK_SIZE
>
> msr CPSR_c,#MODE_IRQ|I_BIT
> mov sp,r0
> sub r0,r0,#IRQ_STACK_SIZE
>
> msr CPSR_c,#MODE_SVC|I_BIT|F_BIT
> mov sp,r0
> sub r0,r0,#SVC_STACK_SIZE
>
> msr CPSR_c,#MODE_SYS|I_BIT|F_BIT
> mov sp,r0
>
> // (This is from FreeRTOS)
> // We want to start in supervisor mode.
> // Operation will switch to system
> // mode when the first task starts.
>
> msr CPSR_c,#MODE_SVC|I_BIT|F_BIT
>
> // Initialization and startup follows
> ....
> --------------------------------------------------
>
> FIQs are not a concern; I use them as a "specialized" reset button
> via EINT3 (it does little more than reset). They are not normally
> triggered.
>
> I even added a check before each interrupt routine. Check it out:
>
> #define INTERRUPT_CHECK \
> { register int _sp asm("sp"); \
> asm volatile ("mov r0,#0x40000000" ); \
> asm volatile ("orr r0,r0,#0x000000e0" ); \
> asm volatile ("orr r0,r0,#0x00007f00" ); \
> asm volatile ("cmp r0,sp" ); \
> asm volatile ("blo 0f" ); \
> asm volatile ("sub r0,r0,#0x00000100" ); \
> asm volatile ("cmp r0,sp" ); \
> asm volatile ("blo 1f" ); \
> asm volatile ("0:" ); \
> error_n1("OUT OF STACK!",_sp); \
> asm volatile ("1:" ); \
> }
>
> void MyFunc(void) __attribute__ ((interrupt("IRQ")));
>
> void MyFunc(void)
> {
> INTERRUPT_CHECK
> /* my code here */
> }
>
> The IRQ stack should be below 0x40007fe0 and is 512 bytes long. The
> error function enters a safe-mode (IRQs disabled, initializes
> hardware, outputs given string or "bad pointer" if problems with
the
> string). The error_n1() function has been tested several times in
> other circumstances and it works like a charm (for instance, it is
> called from the pabt, dabt and undf handlers which DO trigger!).
>
> The stack check from above never fires (except when I tamper with
the
> values just to verify that it WOULD trigger). On the other hand, I
> keep getting undf, dabt and pabt everywhere (i.e., r15 pointing to
> RAM or some weird location) when I start using any SPI interrupt
> routine. I rewritten my program several times, tried many ways, but
> every time the SPI interrupt service routine starts executing, I
get
> a crash sooner or later (within 10 seconds is a good average). This
> doesn't happen with my other interrupt routines, like my two UARTs
or
> the OS timer tick. They work fine. I just don't know what to check
> next. Sometimes the problem doesn't show up for hours if I compile
> with no optimization (-O0) and sometimes it seems to work a little
> longer if I set the processor to run at 10x5 MHz (I usually run it
at
> 10x1 MHz). The system crashed with IRQ routines as simple as this:
>
> static void dummySPIIRQ(void) __attribute__ ((interrupt("IRQ")));
>
> static void dummySPIIRQ(void)
> {
> tdSPI++;
>
> if( S0SPSR & S0SPSR_SPIF )
> {
> IOSET0 = PIN7BIT; // Remove /CS from target SPI device
>
> short rddata = S0SPDR;
> tdSPIRDY = (0xffff & (int) rddata) | 0x80000000;
> }
>
> S0SPINT = 0x01;
> VICVectAddr = 0x00000000;
> }
>
> To worsen things even more, I don't have a JTAG connector on my
> board. Any suggestions will be greately appreciated.
>
> Guille
>
> --- In lpc2000@yahoogroups.com, "Daniel Gelbgras"
> <daniel.gelbgras@e...> wrote:
> >
> > Hi,
> >
> > My guess is that you may want to increase
> > the (normal) interrupt stack *size*
> > and FIQ interrupt stack *size*
> > in your cpu startup (initialization) file
> >
> > For example in Keil startup.s file, these constants are
> > IRQ_Stack_Size and USR_Stack_Size
> >
> >
> > (When you use only a single interrupt, either FIQ or normal
> interrupt,
> > it is working because there is some allocated stack space,
> > but I suppose that one of these 2 constants is too small,
> > so you use the same memory space for both isr's
> >
> > If you enable both interrupts together,
> > one isr can corrupt the register values saved by the other
> isr,
> > and the program crashes after a variable amount of time)
> >
> > HTH
> > kind regards
> > daniel
> > ----- Original Message -----
> > From: Guillermo Prandi
> > To: lpc2000@yahoogroups.com
> > Sent: Saturday, January 21, 2006 10:34 PM
> > Subject: [lpc2000] Re: Non-aligned access?
> >
> >
> > Gary, I wonder if you could solve your problem. I am facing the
> same
> > problem here too. :(
> >
> > Guille
> >
> > --- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...> wrote:
> > >
> > > Definitely seems interrupt related... When I disable the timer
> > > interrupt, the interrupt driven spi works great. When I
> disable the
> > > spi interrupt, the interrupt driven timer works great. When
> both
> > are
> > > enabled, I get about 10 seconds of run time and then the
> program
> > runs
> > > off into the bushes. I'm using Keil w/ GCC, ARM-mode.
What's
> > > special about having two interrupts active that might cause
> this?
> > >
> > > Thanks,
> > >
> > > Gary
> > >
> > > --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> > > >
> > > > Charles Manning wrote:
> > > >
> > > > >On Wednesday 09 November 2005 11:13, Guillermo Prandi
wrote:
> > > > >
> > > > >
> > > > >>Just an idea: perhaps interrupt routines are not
> > saving/restoring all
> > > > >>the registers correctly?
> > > > >>
> > > > >>
> > > > >
> > > > >That would be my first though too.
> > > > >
> > > > >Either that or a stack corruption causing the register to
be
> > nuked,
> > > but that
> > > > >would probably be less likely.
> > > > >
> > > > >Is 40000241H within the RAM address space? If not, what
does
> it
> > > correspond to?
> > > > >
> > > > >If you can figure out how R1 got to have this value you're
> well
> > on
> > > your way to
> > > > >solving the problem.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > I had that, I grapped some project source of an example
> program
> > and
> > > used
> > > > that as the foundation for my project. I got bit by
> > an "__attribute__
> > > > ((naked))" definition of an ISR handler.
> > > >
> > > > TomW
> > > >
> > > > >
> > > > >
> > > > >>Guille
> > > > >>
> > > > >>--- In lpc2000@yahoogroups.com, "ee_gary" <ee_gary@y...>
> wrote:
> > > > >>
> > > > >>
> > > > >>>--- In lpc2000@yahoogroups.com, Charles Manning
> > <manningc2@a...>
> > > > >>>
> > > > >>>
> > > > >>wrote:
> > > > >>
> > > > >>
> > > > >>>>On Tuesday 08 November 2005 14:40, Tom Walsh wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>>ee_gary wrote:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>Hello,
> > > > >>>>>>
> > > > >>>>>>I'm having a problem where my code goes into the
bushes
> > after
> > > > >>>>>>
> > > > >>>>>>
> > > > >>~10
> > > > >>
> > > > >>
> > > > >>
> > > > >>>>>>seconds. Running it in the simulator results in
a "Non-
> > aligned
> > > > >>>>>>Access" error, ARM Instruction at 00000200H, Memory
> Access
> > at
> > > > >>>>>>40000241H. Any idea what that means? Simple code,
> just an
> > > > >>>>>>
> > > > >>>>>>
> > > > >>interrupt
> > > > >>
> > > > >>
> > > > >>
> > > > >>>>>>driven timer and interrupt driven SPI.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>What instruction was this accessing?
> > > > >>>>
> > > > >>>>
> > > > >>>The instruction at 200H was:
> > > > >>>LDR R3,[R1]
> > > > >>>
> > > > >>>It was part of this function:
> > > > >>>void wait (void) {
> > > > >>> unsigned long i;
> > > > >>>
> > > > >>> i = timeval;
> > > > >>> while ((i + 10) != timeval);
> > > > >>>}
> > > > >>>
> > > > >>>where 'timeval' is incremented by an ISR.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>The following things can give you non-aligned accesses:
> > > > >>>>
> > > > >>>>1) Trying to read a U32 on a non-4-byte boundary or a
U16
> on a
> > > > >>>>
> > > > >>>>
> > > > >>>non-2byte
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>boundary. This might raise a data abort.
> > > > >>>>
> > > > >>>>2) Trying to execute an ARM instruction at a non-4-byte
> > location
> > > > >>>>
> > > > >>>>
> > > > >>or
> > > > >>
> > > > >>
> > > > >>
> > > > >>>a thumb
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>instruction at a non-2-byte location. This might raise
a
> > prefetch
> > > > >>>>
> > > > >>>>
> > > > >>abort.
> > > > >>
> > > > >>
> > > > >>
> > > > >>>>>You can run into this when mixing Thumb with ARM code.
> When
> > > > >>>>>
> > > > >>>>>
> > > > >>interrupt
> > > > >>
> > > > >>
> > > > >>
> > > > >>>>>routines are entered, the processor is in ARM mode,
> either
> > > > >>>>>
> > > > >>>>>
> > > > >>write your
> > > > >>
> > > > >>
> > > > >>
> > > > >>>>>handlers in ARM or switch to THUMB mode, process the
> > interrupt,
> > > > >>>>>
> > > > >>>>>
> > > > >>then
> > > > >>
> > > > >>
> > > > >>
> > > > >>>>>exit THUMB mode and return from interrupt.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>Yes, this is possible since thumb addresses are marked
by
> > setting
> > > > >>>>
> > > > >>>>
> > > > >>>the least
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>significant bit. If you try executing the address by
> using a
> > > > >>>>
> > > > >>>>
> > > > >>>regular branch
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>or bl then this will break. You need to use a bx.
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>>FWIW, Thumb, and thumb-internetworking, is too much
> trouble
> > to
> > > > >>>>>
> > > > >>>>>
> > > > >>deal
> > > > >>
> > > > >>
> > > > >>
> > > > >>>>>with, I run strictly ARM mode.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>To each their own, but I strongly disagree. I use thumb
> and
> > > > >>>>
> > > > >>>>
> > > > >>>interworking a
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>lot. gcc support for this is great.
> > > > >>>>
> > > > >>>>I always write all my assembly with interworking (ie
> using bx)
> > > > >>>>
> > > > >>>>
> > > > >>>regardless.
> > > > >>>
> > > > >>>I'm using all ARM code, with the interworking option
> enabled
> > in the
> > > > >>>compiler/linker.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>For an example you might look at the example stuff I
> posted
> > on the
> > > > >>>>
> > > > >>>>
> > > > >>>AT91SAM7
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>>group.
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>Yahoo! Groups Links
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Tom Walsh - WN3L - Embedded Systems Consultant
> > > > http://openhardware.net, http://cyberiansoftware.com
> > > > "Windows? No thanks, I have work to do..."
> > > > ----------------------------------------------------
> > > >
> > >
> >
> >
> >
> >
> >
> >
> > SPONSORED LINKS Microcontrollers Microprocessor Intel
> microprocessors
> > Pic microcontrollers
> >
> >
> > ------------------------------------------------------------------
--
> ----------
> > YAHOO! GROUPS LINKS
> >
> > a.. Visit your group "lpc2000" on the web.
> >
> > b.. To unsubscribe from this group, send an email to:
> > lpc2000-unsubscribe@yahoogroups.com
> >
> > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
> of Service.
> >
> >
> > ------------------------------------------------------------------
--> ---------- > > > > > > > > [Non-text portions of this message have been removed] > > >