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
>
>
>Message
Re: [lpc2000] Re: Non-aligned access?
2005-11-09 by Charles Manning