Lpc2000

I am using gcc and insignt and have problems using Interrupts.
I'm trying to use Timer0 to generate a Interrupt, similar to the Keil
example "blinky", but the interupt is never generatet because the cpsr
register seems to be allways switched back to 0xd0. Looks like my "msr
cpsr_c, #0x10" is ingored or overwriten.
btw... the precompiled keil example works with insight, timer is
running and genarating interrupts.

please help...

I solved the Problem, it was a wrong startupcode that blocked the
modus change.

But now I have the problem that the interrupt causes an exaption, I
think. The ISR is never reached and if I stop the programm the pc is
pointing to 0x7fffe2ae, this must be somewhere in the RAM-mapped
bootloader, how could this happen and how could I fix this?

--- In lpc2000@yahoogroups.com, "digtalfreak" <digitalfreak@n...> wrote:

> I am using gcc and insignt and have problems using Interrupts.
> I'm trying to use Timer0 to generate a Interrupt, similar to the Keil
> example "blinky", but the interupt is never generatet because the cpsr
> register seems to be allways switched back to 0xd0. Looks like my "msr
> cpsr_c, #0x10" is ingored or overwriten.
> btw... the precompiled keil example works with insight, timer is
> running and genarating interrupts.
> 
> please help...

The address you referenced (0x7fffe2ae) is in the boot loader area. 
Somehow your program must have jumped there or ran up to there. The 
boot loader is in Thumb code, so if the rest of your code was ARM, 
you might have generated a Data Abort or Invalid Instruction 
exception when you ran into the thumb code.

Jim

--- In lpc2000@yahoogroups.com, "digtalfreak" <digitalfreak@n...> 
wrote:
> I solved the Problem, it was a wrong startupcode that blocked the
> modus change.
> 
> But now I have the problem that the interrupt causes an exaption, I
> think. The ISR is never reached and if I stop the programm the pc is
> pointing to 0x7fffe2ae, this must be somewhere in the RAM-mapped
> bootloader, how could this happen and how could I fix this?
> 
> --- In lpc2000@yahoogroups.com, "digtalfreak" <digitalfreak@n...> 
wrote:
> > I am using gcc and insignt and have problems using Interrupts.
> > I'm trying to use Timer0 to generate a Interrupt, similar to the 
Keil
> > example "blinky", but the interupt is never generatet because the 
cpsr
> > register seems to be allways switched back to 0xd0. Looks like 
my "msr

> > cpsr_c, #0x10" is ingored or overwriten.
> > btw... the precompiled keil example works with insight, timer is
> > running and genarating interrupts.
> > 
> > please help...

I can't see the reason in my code...
I nearly exactly copied the Keil example and adapted it for my module
and as long as no interrupt is generated everything works fine.

I am using cygwin3.3, gcc3.3.3 and insight6.0 from www.gnuarm.com.

I wrote my own startupcode and linkerscript, maybe the mistake is
there would be nice if someone can send me another working example for
gcc using timerinterrupts and simple led blinking.


--- In lpc2000@yahoogroups.com, "jim_e_dallas" <jim_e_dallas@y...> wrote:

> The address you referenced (0x7fffe2ae) is in the boot loader area. 
> Somehow your program must have jumped there or ran up to there. The 
> boot loader is in Thumb code, so if the rest of your code was ARM, 
> you might have generated a Data Abort or Invalid Instruction 
> exception when you ran into the thumb code.
> 
> Jim
> 
> --- In lpc2000@yahoogroups.com, "digtalfreak" <digitalfreak@n...> 
> wrote:
> > I solved the Problem, it was a wrong startupcode that blocked the
> > modus change.
> > 
> > But now I have the problem that the interrupt causes an exaption, I
> > think. The ISR is never reached and if I stop the programm the pc is
> > pointing to 0x7fffe2ae, this must be somewhere in the RAM-mapped
> > bootloader, how could this happen and how could I fix this?
> > 
> > --- In lpc2000@yahoogroups.com, "digtalfreak" <digitalfreak@n...> 
> wrote:
> > > I am using gcc and insignt and have problems using Interrupts.
> > > I'm trying to use Timer0 to generate a Interrupt, similar to the 
> Keil
> > > example "blinky", but the interupt is never generatet because the 
> cpsr
> > > register seems to be allways switched back to 0xd0. Looks like 
> my "msr
> > > cpsr_c, #0x10" is ingored or overwriten.
> > > btw... the precompiled keil example works with insight, timer is
> > > running and genarating interrupts.
> > > 
> > > please help...

--- In lpc2000@yahoogroups.com, "digtalfreak" <digitalfreak@n...>
wrote:
> I solved the Problem, it was a wrong startupcode that blocked the
> modus change.
> 
> But now I have the problem that the interrupt causes an exaption, I
> think. The ISR is never reached and if I stop the programm the pc is
> pointing to 0x7fffe2ae, this must be somewhere in the RAM-mapped
> bootloader, how could this happen and how could I fix this?
> 
> --- In lpc2000@yahoogroups.com, "digtalfreak" <digitalfreak@n...>
wrote:
> > I am using gcc and insignt and have problems using Interrupts.
> > I'm trying to use Timer0 to generate a Interrupt, similar to the
Keil
> > example "blinky", but the interupt is never generatet because the
cpsr
> > register seems to be allways switched back to 0xd0. Looks like my
"msr
> > cpsr_c, #0x10" is ingored or overwriten.
> > btw... the precompiled keil example works with insight, timer is
> > running and genarating interrupts.
> > 
> > please help...

Hi,

I just came across this group because I have a problem similar to that
of the OP. Did you find a solution meanwhile? 
I'm using gcc 3.2.1 under cygwin and tried to build the blinky_irq
example for a LPC2106. Since it didn't work I stripped the program
down to a bare endless loop in main() and a timer ISR that toggles a
LED an GPIO24. After approx. 3min. the LED stops toggling and I get an
Abort exception. A look at the disassembled code showed that gcc is
messing up the stack pointer in IRQ mode, losing some words every time
the ISR is invoked.
 The code looks the following way:

00000278 <tc0>:
 278:	e52dc004 	str	ip, [sp, -#4]!
 27c:	e1a0c00d 	mov	ip, sp
 280:	e24ee004 	sub	lr, lr, #4	; 0x4
 284:	e92dd80c 	stmdb	sp!, {r2, r3, fp, ip, lr, pc}
 288:	e24cb004 	sub	fp, ip, #4	; 0x4
 28c:	e3a0320e 	mov	r3, #-536870912	; 0xe0000000
 290:	e283390a 	add	r3, r3, #163840	; 0x28000
 294:	e5933000 	ldr	r3, [r3]
 ... some load and store operations on GPIO registers with r2, r3 ...
 2e0:	e3a02000 	mov	r2, #0	; 0x0
 2e4:	e5832000 	str	r2, [r3]
 2e8:	e95b980c 	ldmdb	fp, {r2, r3, fp, ip, pc}^

As you can see, in the beginning registers are saved on the stack thus
decrementing sp. BTW, the way ip is saved in the beginning is
pointless since ip is not restored from that location upon ISR exit.
At the end, registers are restored from stack using fp as base
pointer. The pc is loaded with the adjusted return address and
simultaneously cpsr is restored from spsr_irq. Sp however is not
restored so that at ISR exit sp is seven words lower than at ISR
entry.
Either I missed some point when building the program (e.g. forgot
certain gcc options) or gcc 3.2.1 is buggy here.
Options I use are  "-mcpu=arm7tdmi -gstabs" for the assembly of
startup.s and "-c -g -I. -mcpu=arm7tdmi" for compiling of C-source
files. Linker options are "-T Flash.ld -nostartfiles -Lgcc -L.", where
Flash.ld is the linker script supplied with Keil's blinky_irq example
adjusted to the actual Flash and RAM sizes of the LPC2106.
Has anybody else in the group encountered similar problems and if so,
have you found a solution?

TIA,
Jens

At 07:20 PM 6/14/04 +0000, you wrote:
>of the OP. Did you find a solution meanwhile?
>I'm using gcc 3.2.1 under cygwin and tried to build the blinky_irq
>example for a LPC2106. Since it didn't work I stripped the program
>down to a bare endless loop in main() and a timer ISR that toggles a
>LED an GPIO24. After approx. 3min. the LED stops toggling and I get an
>Abort exception. A look at the disassembled code showed that gcc is
>messing up the stack pointer in IRQ mode, losing some words every time
>the ISR is invoked.

Well, there has been (is?) a problem with interrupts on the ARM using 
GCC.  There should be others lurking here with more information on that. 
BTW, I just checked I'm using 3.3.2 and it's not that new.  If you are just 
starting I'd really seriously consider a newer version.

I don't trust compilers for this sort of thing anyway.  More fodder for my 
paranoia :)

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

--- In lpc2000@yahoogroups.com, "friese99de" <jens.hildebrandt@e...> 
wrote:
> Hi,
> 
> I just came across this group because I have a problem similar to 
that
> of the OP. Did you find a solution meanwhile? 
> I'm using gcc 3.2.1 under cygwin and tried to build the blinky_irq
> example for a LPC2106. Since it didn't work I stripped the program
> down to a bare endless loop in main() and a timer ISR that toggles a
> LED an GPIO24. After approx. 3min. the LED stops toggling and I get 
an
> Abort exception. A look at the disassembled code showed that gcc is
> messing up the stack pointer in IRQ mode, losing some words every 
time
> the ISR is invoked.
>  The code looks the following way:
> 
> 00000278 <tc0>:
>  278:	e52dc004 	str	ip, [sp, -#4]!
>  27c:	e1a0c00d 	mov	ip, sp
>  280:	e24ee004 	sub	lr, lr, #4	; 0x4
>  284:	e92dd80c 	stmdb	sp!, {r2, r3, fp, ip, lr, pc}
>  288:	e24cb004 	sub	fp, ip, #4	; 0x4
>  28c:	e3a0320e 	mov	r3, #-536870912	; 0xe0000000
>  290:	e283390a 	add	r3, r3, #163840	; 0x28000
>  294:	e5933000 	ldr	r3, [r3]
>  ... some load and store operations on GPIO registers with r2, 
r3 ...
>  2e0:	e3a02000 	mov	r2, #0	; 0x0
>  2e4:	e5832000 	str	r2, [r3]
>  2e8:	e95b980c 	ldmdb	fp, {r2, r3, fp, ip, pc}^
> 
> As you can see, in the beginning registers are saved on the stack 
thus
> decrementing sp. BTW, the way ip is saved in the beginning is
> pointless since ip is not restored from that location upon ISR exit.
> At the end, registers are restored from stack using fp as base
> pointer. The pc is loaded with the adjusted return address and
> simultaneously cpsr is restored from spsr_irq. Sp however is not
> restored so that at ISR exit sp is seven words lower than at ISR
> entry.
> Either I missed some point when building the program (e.g. forgot
> certain gcc options) or gcc 3.2.1 is buggy here.
> Options I use are  "-mcpu=arm7tdmi -gstabs" for the assembly of
> startup.s and "-c -g -I. -mcpu=arm7tdmi" for compiling of C-source
> files. Linker options are "-T Flash.ld -nostartfiles -Lgcc -L.", 
where
> Flash.ld is the linker script supplied with Keil's blinky_irq 
example
> adjusted to the actual Flash and RAM sizes of the LPC2106.
> Has anybody else in the group encountered similar problems and if 
so,
> have you found a solution?

The interrupt entry and exit code in gcc 3.2.x and older doesn't 
work.  Either upgrade to gcc 3.3.x, where it works, or write the 
entry/exit code yourself.

Regards,
Karl Olsen

Karl Olsen wrote:

> --- In lpc2000@yahoogroups.com, "friese99de" <jens.hildebrandt@e...> 
> wrote:
> 
>>Hi,
>>
>>I just came across this group because I have a problem similar to 
> 
> that
> 
>>of the OP. Did you find a solution meanwhile? 
>>I'm using gcc 3.2.1 under cygwin and tried to build the blinky_irq
>>example for a LPC2106. Since it didn't work I stripped the program
>>down to a bare endless loop in main() and a timer ISR that toggles a
>>LED an GPIO24. After approx. 3min. the LED stops toggling and I get 
> 
> an
> 
>>Abort exception. A look at the disassembled code showed that gcc is
>>messing up the stack pointer in IRQ mode, losing some words every 
> 
> time
> 
>>the ISR is invoked.
>> The code looks the following way:
>>
>>00000278 <tc0>:
>> 278:	e52dc004 	str	ip, [sp, -#4]!
>> 27c:	e1a0c00d 	mov	ip, sp
>> 280:	e24ee004 	sub	lr, lr, #4	; 0x4
>> 284:	e92dd80c 	stmdb	sp!, {r2, r3, fp, ip, lr, pc}
>> 288:	e24cb004 	sub	fp, ip, #4	; 0x4
>> 28c:	e3a0320e 	mov	r3, #-536870912	; 0xe0000000
>> 290:	e283390a 	add	r3, r3, #163840	; 0x28000
>> 294:	e5933000 	ldr	r3, [r3]
>> ... some load and store operations on GPIO registers with r2, 
> 
> r3 ...
> 
>> 2e0:	e3a02000 	mov	r2, #0	; 0x0
>> 2e4:	e5832000 	str	r2, [r3]
>> 2e8:	e95b980c 	ldmdb	fp, {r2, r3, fp, ip, pc}^
>>
>>As you can see, in the beginning registers are saved on the stack 
> 
> thus
> 
>>decrementing sp. BTW, the way ip is saved in the beginning is
>>pointless since ip is not restored from that location upon ISR exit.
>>At the end, registers are restored from stack using fp as base
>>pointer. The pc is loaded with the adjusted return address and
>>simultaneously cpsr is restored from spsr_irq. Sp however is not
>>restored so that at ISR exit sp is seven words lower than at ISR
>>entry.
>>Either I missed some point when building the program (e.g. forgot
>>certain gcc options) or gcc 3.2.1 is buggy here.
>>Options I use are  "-mcpu=arm7tdmi -gstabs" for the assembly of
>>startup.s and "-c -g -I. -mcpu=arm7tdmi" for compiling of C-source
>>files. Linker options are "-T Flash.ld -nostartfiles -Lgcc -L.", 
> 
> where
> 
>>Flash.ld is the linker script supplied with Keil's blinky_irq 
> 
> example
> 
>>adjusted to the actual Flash and RAM sizes of the LPC2106.
>>Has anybody else in the group encountered similar problems and if 
> 
> so,
> 
>>have you found a solution?
> 
> 
> The interrupt entry and exit code in gcc 3.2.x and older doesn't 
> work.  Either upgrade to gcc 3.3.x, where it works, or write the 
> entry/exit code yourself.
> 
> Regards,
> Karl Olsen
> 
> 
> 
>
>  
> 
> 

Hi Karl,

thanks for the clear answer. I just wanted to be sure that an upgrade of gcc 
wouldn't be in vain (at least with respect to my problem).

Regards,
Jens

--- In lpc2000@yahoogroups.com, Jens Hildebrandt
<jens.hildebrandt@e...> wrote:
> Karl Olsen wrote:
> > The interrupt entry and exit code in gcc 3.2.x and older doesn't 
> > work.  Either upgrade to gcc 3.3.x, where it works, or write the 
> > entry/exit code yourself.
> > 
> > Regards,
> > Karl Olsen
> >  
> 
> Hi Karl,
> 
> thanks for the clear answer. I just wanted to be sure that an
upgrade of gcc 
> wouldn't be in vain (at least with respect to my problem).
> 
> Regards,
> Jens
Hi:
I checked a code with GCC 3.4.0 and the code generated seems to be
logically correct:

The following C code for testing GCC 3.4 Interrupt handling capability
created the ARM assembler code shown below the C code:
                                                                     
                
C code:
-------------------------------------------------
void isr_IRQ()  __attribute__((interrupt("IRQ")));
extern void dummy();
void isr_IRQ()
{
        dummy();
}
------------------------------------------------
Assembler Code:
--------------------------------
        .file   "testInt.c"
        .text
        .align  2
        .global isr_IRQ
        .type   isr_IRQ, %function
isr_IRQ:
        @ Interrupt Service Routine.
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        str     ip, [sp, #-4]!  
        mov     ip, sp          
        stmfd   sp!, {r0, r1, r2, r3, fp, ip, lr, pc} 
        sub     fp, ip, #4      
        bl      dummy           
        ldmfd   sp, {r0, r1, r2, r3, fp, sp, lr} 
        ldmfd   sp!, {ip}       
        subs    pc, lr, #4      // load pc with next instruction from
interrupted program and restore CPSR (note the s bit)
        .size   isr_IRQ, .-isr_IRQ
        .ident  "GCC: (GNU) 3.4.0"
----------------------------------------                             
        
I don't have a system to check it out. Could anyone confirm if this is
OK? 
Regards
Mathew

--- In lpc2000@yahoogroups.com, "jpmarm2004" <jpmarm2004@y...> wrote:
> --- In lpc2000@yahoogroups.com, Jens Hildebrandt
> <jens.hildebrandt@e...> wrote:
> > Karl Olsen wrote:
> > > The interrupt entry and exit code in gcc 3.2.x and older doesn't 
> > > work.  Either upgrade to gcc 3.3.x, where it works, or write the 
> > > entry/exit code yourself.
> > > 
> > > Regards,
> > > Karl Olsen
> > >  
> > 
> > Hi Karl,
> > 
> > thanks for the clear answer. I just wanted to be sure that an
> upgrade of gcc 
> > wouldn't be in vain (at least with respect to my problem).
> > 
> > Regards,
> > Jens
> Hi:
> I checked a code with GCC 3.4.0 and the code generated seems to be
> logically correct:
> 
> The following C code for testing GCC 3.4 Interrupt handling capability
> created the ARM assembler code shown below the C code:
>                                                                      
>                 
> C code:
> -------------------------------------------------
> void isr_IRQ()  __attribute__((interrupt("IRQ")));
> extern void dummy();
> void isr_IRQ()
> {
>         dummy();
> }
> ------------------------------------------------
> Assembler Code:
> --------------------------------
>         .file   "testInt.c"
>         .text
>         .align  2
>         .global isr_IRQ
>         .type   isr_IRQ, %function
> isr_IRQ:
>         @ Interrupt Service Routine.
>         @ args = 0, pretend = 0, frame = 0
>         @ frame_needed = 1, uses_anonymous_args = 0
>         str     ip, [sp, #-4]!  
>         mov     ip, sp          
>         stmfd   sp!, {r0, r1, r2, r3, fp, ip, lr, pc} 
>         sub     fp, ip, #4      
>         bl      dummy           
>         ldmfd   sp, {r0, r1, r2, r3, fp, sp, lr} 
>         ldmfd   sp!, {ip}       
>         subs    pc, lr, #4      // load pc with next instruction from
> interrupted program and restore CPSR (note the s bit)
>         .size   isr_IRQ, .-isr_IRQ
>         .ident  "GCC: (GNU) 3.4.0"
> ----------------------------------------                             
>         
> I don't have a system to check it out. Could anyone confirm if this is
> OK? 
> Regards
> Mathew
My apologies (newbie!)
I don't think subs instruction has the s bit set!
Could someone tell me how the CPSR is restored in the above code ?
Regards
Mathew

jpmarm2004 wrote:

> --- In lpc2000@yahoogroups.com, "jpmarm2004" <jpmarm2004@y...> wrote:
> 
>>--- In lpc2000@yahoogroups.com, Jens Hildebrandt
>><jens.hildebrandt@e...> wrote:
>>
>>>Karl Olsen wrote:
>>>
>>>>The interrupt entry and exit code in gcc 3.2.x and older doesn't 
>>>>work.  Either upgrade to gcc 3.3.x, where it works, or write the 
>>>>entry/exit code yourself.
>>>>
>>>>Regards,
>>>>Karl Olsen
>>>> 
>>>
>>>Hi Karl,
>>>
>>>thanks for the clear answer. I just wanted to be sure that an
>>
>>upgrade of gcc 
>>
>>>wouldn't be in vain (at least with respect to my problem).
>>>
>>>Regards,
>>>Jens
>>
>>Hi:
>>I checked a code with GCC 3.4.0 and the code generated seems to be
>>logically correct:
>>
>>The following C code for testing GCC 3.4 Interrupt handling capability
>>created the ARM assembler code shown below the C code:
>>                                                                     
>>                
>>C code:
>>-------------------------------------------------
>>void isr_IRQ()  __attribute__((interrupt("IRQ")));
>>extern void dummy();
>>void isr_IRQ()
>>{
>>        dummy();
>>}
>>------------------------------------------------
>>Assembler Code:
>>--------------------------------
>>        .file   "testInt.c"
>>        .text
>>        .align  2
>>        .global isr_IRQ
>>        .type   isr_IRQ, %function
>>isr_IRQ:
>>        @ Interrupt Service Routine.
>>        @ args = 0, pretend = 0, frame = 0
>>        @ frame_needed = 1, uses_anonymous_args = 0
>>        str     ip, [sp, #-4]!  
>>        mov     ip, sp          
>>        stmfd   sp!, {r0, r1, r2, r3, fp, ip, lr, pc} 
>>        sub     fp, ip, #4      
>>        bl      dummy           
>>        ldmfd   sp, {r0, r1, r2, r3, fp, sp, lr} 
>>        ldmfd   sp!, {ip}       
>>        subs    pc, lr, #4      // load pc with next instruction from
>>interrupted program and restore CPSR (note the s bit)
>>        .size   isr_IRQ, .-isr_IRQ
>>        .ident  "GCC: (GNU) 3.4.0"
>>----------------------------------------                             
>>        
>>I don't have a system to check it out. Could anyone confirm if this is
>>OK? 
>>Regards
>>Mathew
> 
> My apologies (newbie!)
> I don't think subs instruction has the s bit set!
> Could someone tell me how the CPSR is restored in the above code ?
> Regards
> Mathew
> 
The last subs instruction has the S flag set (that's why it's called sub*s*, op 
code here is 0xe25ef004) and since the destination register is r15 this causes 
the CPSR to be loaded with the contents of SPSR.
I checked my formerly non-working code after upgrading to gcc-3.4.0 and it looks 
the way your code does. And what's more important - the code works, no more lost 
words on the stack.

Regards,
Jens