http://pastebin.com/i2ygBjxp
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" vltzzzzzzz@ wrote:
>
> > Thanks that was easy, everything compiled fine, but when I tried to
run
> > it on the board I got no output, I then tried
running it in the keil
> > software debugger and it appears to hang once it reach's the
timer_init
> > function, seems like it is getting stuck in the
isr as variables in
the
> > there are getting continually updated.
> >
> > The only reason I was going to change the linker script is for the
> > reason you highlighted. I thought it would be easier just to use the
> > crt.s that you uploaded only to find out when I tried that the
linker
> > was missing definitions from the other...
> >
> > Here is the updated version of the startup file -I followed what you
> > said so I presume everything is fine.
> >
> > http://pastebin.com/zgcRDKbq
> >
> > Regards,
> > J
> > The startup file looks ok and do the two timer init functions although
I didn't really try to figure out what they are doing.
>
> You haven't posted the code for your two interrupt handlers. In which
ISR is the code getting stuck?
>
> I have never used the Keil debugger.
>
> You are right, it is better to swap out both the startup and linker
files as a set. There's no reason not to do that.
>
> Richard
>
Ive been debugging and thinking...
A variable in timer0 is altered every time the isr is run- this is
still happening so it would appear that the isr is being reexcuted
rather than been stuck in there.
Although once the first interrupt occurs no other code is executed
after, and if single stepping through code, step, step over and run etc
are greyed out.
The timer peripheral window (in the debugger ) show the timer to be both
enabled and reset, so TC is stuck at 0, Timer0 is configured to
interrupt on MR0.
Which ever timer interrupts first causes the problem.
isr's
http://pastebin.com/9cVi5nAk
I tried using the linker file you provide but I got some errors.
linker error msgs, using crt.s with lpc2106_FLASH.ld
http://pastebin.com/i2ygBjxp
Regards,
J
LPC2106 GNU CodeSourcery Toolchain: How to enable nested interrupts
Started by ●April 22, 2010
Reply by ●April 23, 20102010-04-23
Reply by ●April 23, 20102010-04-23
Quoting voltz56 :
> http://pastebin.com/i2ygBjxp
> --- In l..., "rtstofer" wrote:
>>
>> --- In l..., "voltz56" vltzzzzzzz@ wrote:
>>
>> > Thanks that was easy, everything compiled fine, but when I tried to
> run
>> > it on the board I got no output, I then tried running it in the keil
>> > software debugger and it appears to hang once it reach's the
> timer_init
>> > function, seems like it is getting stuck in the isr as variables in
> the
>> > there are getting continually updated.
>> >
>> > The only reason I was going to change the linker script is for the
>> > reason you highlighted. I thought it would be easier just to use the
>> > crt.s that you uploaded only to find out when I tried that the
> linker
>> > was missing definitions from the other...
>> >
>> > Here is the updated version of the startup file -I followed what you
>> > said so I presume everything is fine.
>> >
>> > http://pastebin.com/zgcRDKbq
>> >
>> > Regards,
>> > J
>> >
>>
>> The startup file looks ok and do the two timer init functions although
> I didn't really try to figure out what they are doing.
>>
>> You haven't posted the code for your two interrupt handlers. In which
> ISR is the code getting stuck?
>>
>> I have never used the Keil debugger.
>>
>> You are right, it is better to swap out both the startup and linker
> files as a set. There's no reason not to do that.
>>
>> Richard
>>
> Ive been debugging and thinking...
> A variable in timer0 is altered every time the isr is run- this is
> still happening so it would appear that the isr is being reexcuted
> rather than been stuck in there.
> Although once the first interrupt occurs no other code is executed
> after, and if single stepping through code, step, step over and run etc
> are greyed out.
> The timer peripheral window (in the debugger ) show the timer to be both
> enabled and reset, so TC is stuck at 0, Timer0 is configured to
> interrupt on MR0.
> Which ever timer interrupts first causes the problem.
>
> isr's
>
> http://pastebin.com/9cVi5nAk I tried using the linker file you provide but I got some errors.
>
> linker error msgs, using crt.s with lpc2106_FLASH.ld
> http://pastebin.com/i2ygBjxp Regards,
> J
It may not be a good idea to do your LCD updating in the ISR, unless these
routines can handle a recursive call (ie. are reentrant). If these routines
are also called from non-ISR code, the chances of one of them getting called
while in the middle of itself is likely.
Check to see if the VICVectAddr dummy write is handled in your ISR wrapper
function. This is often where this is handled, so you don't need to put
it in your handler function.
Mike
> http://pastebin.com/i2ygBjxp
> --- In l..., "rtstofer" wrote:
>>
>> --- In l..., "voltz56" vltzzzzzzz@ wrote:
>>
>> > Thanks that was easy, everything compiled fine, but when I tried to
> run
>> > it on the board I got no output, I then tried running it in the keil
>> > software debugger and it appears to hang once it reach's the
> timer_init
>> > function, seems like it is getting stuck in the isr as variables in
> the
>> > there are getting continually updated.
>> >
>> > The only reason I was going to change the linker script is for the
>> > reason you highlighted. I thought it would be easier just to use the
>> > crt.s that you uploaded only to find out when I tried that the
> linker
>> > was missing definitions from the other...
>> >
>> > Here is the updated version of the startup file -I followed what you
>> > said so I presume everything is fine.
>> >
>> > http://pastebin.com/zgcRDKbq
>> >
>> > Regards,
>> > J
>> >
>>
>> The startup file looks ok and do the two timer init functions although
> I didn't really try to figure out what they are doing.
>>
>> You haven't posted the code for your two interrupt handlers. In which
> ISR is the code getting stuck?
>>
>> I have never used the Keil debugger.
>>
>> You are right, it is better to swap out both the startup and linker
> files as a set. There's no reason not to do that.
>>
>> Richard
>>
> Ive been debugging and thinking...
> A variable in timer0 is altered every time the isr is run- this is
> still happening so it would appear that the isr is being reexcuted
> rather than been stuck in there.
> Although once the first interrupt occurs no other code is executed
> after, and if single stepping through code, step, step over and run etc
> are greyed out.
> The timer peripheral window (in the debugger ) show the timer to be both
> enabled and reset, so TC is stuck at 0, Timer0 is configured to
> interrupt on MR0.
> Which ever timer interrupts first causes the problem.
>
> isr's
>
> http://pastebin.com/9cVi5nAk I tried using the linker file you provide but I got some errors.
>
> linker error msgs, using crt.s with lpc2106_FLASH.ld
> http://pastebin.com/i2ygBjxp Regards,
> J
It may not be a good idea to do your LCD updating in the ISR, unless these
routines can handle a recursive call (ie. are reentrant). If these routines
are also called from non-ISR code, the chances of one of them getting called
while in the middle of itself is likely.
Check to see if the VICVectAddr dummy write is handled in your ISR wrapper
function. This is often where this is handled, so you don't need to put
it in your handler function.
Mike
Reply by ●April 23, 20102010-04-23
You have to reset the VIC hardware that tells it the interrupt has
been serviced. Below is some code that
catches eint2, and increments two variables. One tells the
application the interrupt has occurred, and the other is a debugging
counter.
After that you reset the external interrupt, and finally the VIC
hardware. The user manual explains all of this.
#include
#if defined (VICVectAddr)
.equ vic_vect_addr, VICVectAddr
#elif defined (VICAddress)
.equ vic_vect_addr, VICAddress
#else
# error "Can't set vic_vect_addr."
#endif
.equ extint, EXTINT
.equ eint2_clear, 0x04
.text
.arm
.global slave_ready_isr
.func slave_ready_isr
slave_ready_isr:
sub lr, lr, #4 /* lr = irq return address */
stmdb sp!, {r0, r1, lr}
mrs r1, spsr /* cpsr of interrupted */
stmfd sp!, {r1}
ldr r0, =slave_ready_flag /* inc application flag */
ldr r1, [r0]
add r1, r1, #1
str r1, [r0]
ldr r0, =slave_irq_ctr /* fixme - testing */
ldr r1, [r0]
add r1, r1, #1
str r1, [r0]
ldr r0, =extint /* clear the interrupt */
mov r1, #eint2_clear /* write ones to clear */
str r1, [r0]
ldr r0, =vic_vect_addr
mvn r1, #0 /* r1 = -1 */
str r1, [r0] /* reset VIC hardware */
ldmfd sp!, {r1} /* restore cpsr of interrupted */
msr spsr_fsxc, r1
ldmia sp!, {r0, r1, pc}^
.endfunc
.end
DaveS
On Fri, Apr 23, 2010 at 1:38 PM, voltz56 wrote:
>
> --- In l..., "voltz56" wrote:
>>
>> --- In l..., "rtstofer" wrote:
>> >
>> >
>> >
>> > --- In l..., "voltz56" wrote:
>> >
>> > > Thanks that was easy, everything compiled fine, but when I tried to run
>> > > it on the board I got no output, I then tried running it in the keil
>> > > software debugger and it appears to hang once it reach's the timer_init
>> > > function, seems like it is getting stuck in the isr as variables in the
>> > > there are getting continually updated.
>> > >
>> > > The only reason I was going to change the linker script is for the
>> > > reason you highlighted. I thought it would be easier just to use the
>> > > crt.s that you uploaded only to find out when I tried that the linker
>> > > was missing definitions from the other...
>> > >
>> > > Here is the updated version of the startup file -I followed what you
>> > > said so I presume everything is fine.
>> > >
>> > > http://pastebin.com/zgcRDKbq
>> > >
>> > > Regards,
>> > > J
>> > >
>> >
>> > The startup file looks ok and do the two timer init functions although I didn't really try to figure out what they are doing.
>> >
>> > You haven't posted the code for your two interrupt handlers. In which ISR is the code getting stuck?
>> >
>> > I have never used the Keil debugger.
>> >
>> > You are right, it is better to swap out both the startup and linker files as a set. There's no reason not to do that.
>> >
>> > Richard
>> >
>>
>> Ive been debugging and thinking...
>> A variable in timer0 is altered every time the isr is run- this is still happening so it would appear that the isr is being reexcuted rather than been stuck in there.
>> Although once the first interrupt occurs no other code is executed after, and if single stepping through code, step, step over and run etc are greyed out, which suggests to me that is has hung.
>> The timer peripheral window (in the debugger ) show the timer to be both enabled and reset, so TC is stuck at 0, Timer0 is configured to interrupt on MR0.
>> Which ever timer interrupts first causes the problem.
>>
>> isr's
>>
>> http://pastebin.com/9cVi5nAk
>>
>> I tried using the linker file you provide but I got some errors.
>>
>> linker error msgs, using crt.s with lpc2106_FLASH.ld
>> http://pastebin.com/i2ygBjxp
>>
>> Regards,
>> J
>> I decided to comment out the init for timer0 and test just timer1, everything looks ok in the timer peripheral window in the debugger, TC is incrementing, and the timer is interrupting on match and on capture. The code in the isr is also doing its job as it should be. The problem still remains though that it doesn't execute any code after the timer init function (apart from the timer1 isr).
>
been serviced. Below is some code that
catches eint2, and increments two variables. One tells the
application the interrupt has occurred, and the other is a debugging
counter.
After that you reset the external interrupt, and finally the VIC
hardware. The user manual explains all of this.
#include
#if defined (VICVectAddr)
.equ vic_vect_addr, VICVectAddr
#elif defined (VICAddress)
.equ vic_vect_addr, VICAddress
#else
# error "Can't set vic_vect_addr."
#endif
.equ extint, EXTINT
.equ eint2_clear, 0x04
.text
.arm
.global slave_ready_isr
.func slave_ready_isr
slave_ready_isr:
sub lr, lr, #4 /* lr = irq return address */
stmdb sp!, {r0, r1, lr}
mrs r1, spsr /* cpsr of interrupted */
stmfd sp!, {r1}
ldr r0, =slave_ready_flag /* inc application flag */
ldr r1, [r0]
add r1, r1, #1
str r1, [r0]
ldr r0, =slave_irq_ctr /* fixme - testing */
ldr r1, [r0]
add r1, r1, #1
str r1, [r0]
ldr r0, =extint /* clear the interrupt */
mov r1, #eint2_clear /* write ones to clear */
str r1, [r0]
ldr r0, =vic_vect_addr
mvn r1, #0 /* r1 = -1 */
str r1, [r0] /* reset VIC hardware */
ldmfd sp!, {r1} /* restore cpsr of interrupted */
msr spsr_fsxc, r1
ldmia sp!, {r0, r1, pc}^
.endfunc
.end
DaveS
On Fri, Apr 23, 2010 at 1:38 PM, voltz56 wrote:
>
> --- In l..., "voltz56" wrote:
>>
>> --- In l..., "rtstofer" wrote:
>> >
>> >
>> >
>> > --- In l..., "voltz56" wrote:
>> >
>> > > Thanks that was easy, everything compiled fine, but when I tried to run
>> > > it on the board I got no output, I then tried running it in the keil
>> > > software debugger and it appears to hang once it reach's the timer_init
>> > > function, seems like it is getting stuck in the isr as variables in the
>> > > there are getting continually updated.
>> > >
>> > > The only reason I was going to change the linker script is for the
>> > > reason you highlighted. I thought it would be easier just to use the
>> > > crt.s that you uploaded only to find out when I tried that the linker
>> > > was missing definitions from the other...
>> > >
>> > > Here is the updated version of the startup file -I followed what you
>> > > said so I presume everything is fine.
>> > >
>> > > http://pastebin.com/zgcRDKbq
>> > >
>> > > Regards,
>> > > J
>> > >
>> >
>> > The startup file looks ok and do the two timer init functions although I didn't really try to figure out what they are doing.
>> >
>> > You haven't posted the code for your two interrupt handlers. In which ISR is the code getting stuck?
>> >
>> > I have never used the Keil debugger.
>> >
>> > You are right, it is better to swap out both the startup and linker files as a set. There's no reason not to do that.
>> >
>> > Richard
>> >
>>
>> Ive been debugging and thinking...
>> A variable in timer0 is altered every time the isr is run- this is still happening so it would appear that the isr is being reexcuted rather than been stuck in there.
>> Although once the first interrupt occurs no other code is executed after, and if single stepping through code, step, step over and run etc are greyed out, which suggests to me that is has hung.
>> The timer peripheral window (in the debugger ) show the timer to be both enabled and reset, so TC is stuck at 0, Timer0 is configured to interrupt on MR0.
>> Which ever timer interrupts first causes the problem.
>>
>> isr's
>>
>> http://pastebin.com/9cVi5nAk
>>
>> I tried using the linker file you provide but I got some errors.
>>
>> linker error msgs, using crt.s with lpc2106_FLASH.ld
>> http://pastebin.com/i2ygBjxp
>>
>> Regards,
>> J
>> I decided to comment out the init for timer0 and test just timer1, everything looks ok in the timer peripheral window in the debugger, TC is incrementing, and the timer is interrupting on match and on capture. The code in the isr is also doing its job as it should be. The problem still remains though that it doesn't execute any code after the timer init function (apart from the timer1 isr).
>
Reply by ●April 23, 20102010-04-23
--- In l..., Michael Anton wrote:
> Check to see if the VICVectAddr dummy write is handled in your ISR wrapper
> function. This is often where this is handled, so you don't need to put
> it in your handler function.
>
> Mike
>
This is an important point! The wrapper code does indeed acknowledge the interrupts. This VICVectAddr write should not be inside the C functions.
Richard
> Check to see if the VICVectAddr dummy write is handled in your ISR wrapper
> function. This is often where this is handled, so you don't need to put
> it in your handler function.
>
> Mike
>
This is an important point! The wrapper code does indeed acknowledge the interrupts. This VICVectAddr write should not be inside the C functions.
Richard
Reply by ●April 24, 20102010-04-24
--- In l..., "rtstofer" wrote:
>
> --- In l..., Michael Anton manton@ wrote:
>
> > Check to see if the VICVectAddr dummy write is handled in your ISR
wrapper
> > function. This is often where this is handled, so you don't need to
put
> > it in your handler function.
> >
> > Mike
> > This is an important point! The wrapper code does indeed acknowledge
the interrupts. This VICVectAddr write should not be inside the C
functions.
>
> Richard
>
I removed that but it didnt make difference as far as I can see. I did
notice though I had forgotten to remove the __attribute__ ((interrupt))
from the isr prototypes. I debugged a little with them removed and found
that the program will only run to the end of the first isr to be called
rather continually executing the first called...
Regards,
V
>
> --- In l..., Michael Anton manton@ wrote:
>
> > Check to see if the VICVectAddr dummy write is handled in your ISR
wrapper
> > function. This is often where this is handled, so you don't need to
put
> > it in your handler function.
> >
> > Mike
> > This is an important point! The wrapper code does indeed acknowledge
the interrupts. This VICVectAddr write should not be inside the C
functions.
>
> Richard
>
I removed that but it didnt make difference as far as I can see. I did
notice though I had forgotten to remove the __attribute__ ((interrupt))
from the isr prototypes. I debugged a little with them removed and found
that the program will only run to the end of the first isr to be called
rather continually executing the first called...
Regards,
V
Reply by ●April 24, 20102010-04-24
--- In l..., Michael Anton wrote:
>
> Quoting voltz56 :
>
> > http://pastebin.com/i2ygBjxp
> > --- In l..., "rtstofer" wrote:
> >>
> >>
> >>
> >> --- In l..., "voltz56" vltzzzzzzz@ wrote:
> >>
> >> > Thanks that was easy, everything compiled fine, but when I tried to
> > run
> >> > it on the board I got no output, I then tried running it in the keil
> >> > software debugger and it appears to hang once it reach's the
> > timer_init
> >> > function, seems like it is getting stuck in the isr as variables in
> > the
> >> > there are getting continually updated.
> >> >
> >> > The only reason I was going to change the linker script is for the
> >> > reason you highlighted. I thought it would be easier just to use the
> >> > crt.s that you uploaded only to find out when I tried that the
> > linker
> >> > was missing definitions from the other...
> >> >
> >> > Here is the updated version of the startup file -I followed what you
> >> > said so I presume everything is fine.
> >> >
> >> > http://pastebin.com/zgcRDKbq
> >> >
> >> > Regards,
> >> > J
> >> >
> >>
> >> The startup file looks ok and do the two timer init functions although
> > I didn't really try to figure out what they are doing.
> >>
> >> You haven't posted the code for your two interrupt handlers. In which
> > ISR is the code getting stuck?
> >>
> >> I have never used the Keil debugger.
> >>
> >> You are right, it is better to swap out both the startup and linker
> > files as a set. There's no reason not to do that.
> >>
> >> Richard
> >>
> > Ive been debugging and thinking...
> > A variable in timer0 is altered every time the isr is run- this is
> > still happening so it would appear that the isr is being reexcuted
> > rather than been stuck in there.
> > Although once the first interrupt occurs no other code is executed
> > after, and if single stepping through code, step, step over and run etc
> > are greyed out.
> > The timer peripheral window (in the debugger ) show the timer to be both
> > enabled and reset, so TC is stuck at 0, Timer0 is configured to
> > interrupt on MR0.
> > Which ever timer interrupts first causes the problem.
> >
> > isr's
> >
> > http://pastebin.com/9cVi5nAk
> >
> > I tried using the linker file you provide but I got some errors.
> >
> > linker error msgs, using crt.s with lpc2106_FLASH.ld
> > http://pastebin.com/i2ygBjxp
> >
> > Regards,
> > J
> >
> > It may not be a good idea to do your LCD updating in the ISR, unless these
> routines can handle a recursive call (ie. are reentrant). If these routines
> are also called from non-ISR code, the chances of one of them getting called
> while in the middle of itself is likely.
>
> Check to see if the VICVectAddr dummy write is handled in your ISR wrapper
> function. This is often where this is handled, so you don't need to put
> it in your handler function.
>
> Mike
>
I not quite sure how recursion would work in that context, LCD routines will only be called in the isr so -that should not be a problem?
Removing the VICTVEctAddr dummy write hasn't made noticeable difference.
Regards,
J
>
> Quoting voltz56 :
>
> > http://pastebin.com/i2ygBjxp
> > --- In l..., "rtstofer" wrote:
> >>
> >>
> >>
> >> --- In l..., "voltz56" vltzzzzzzz@ wrote:
> >>
> >> > Thanks that was easy, everything compiled fine, but when I tried to
> > run
> >> > it on the board I got no output, I then tried running it in the keil
> >> > software debugger and it appears to hang once it reach's the
> > timer_init
> >> > function, seems like it is getting stuck in the isr as variables in
> > the
> >> > there are getting continually updated.
> >> >
> >> > The only reason I was going to change the linker script is for the
> >> > reason you highlighted. I thought it would be easier just to use the
> >> > crt.s that you uploaded only to find out when I tried that the
> > linker
> >> > was missing definitions from the other...
> >> >
> >> > Here is the updated version of the startup file -I followed what you
> >> > said so I presume everything is fine.
> >> >
> >> > http://pastebin.com/zgcRDKbq
> >> >
> >> > Regards,
> >> > J
> >> >
> >>
> >> The startup file looks ok and do the two timer init functions although
> > I didn't really try to figure out what they are doing.
> >>
> >> You haven't posted the code for your two interrupt handlers. In which
> > ISR is the code getting stuck?
> >>
> >> I have never used the Keil debugger.
> >>
> >> You are right, it is better to swap out both the startup and linker
> > files as a set. There's no reason not to do that.
> >>
> >> Richard
> >>
> > Ive been debugging and thinking...
> > A variable in timer0 is altered every time the isr is run- this is
> > still happening so it would appear that the isr is being reexcuted
> > rather than been stuck in there.
> > Although once the first interrupt occurs no other code is executed
> > after, and if single stepping through code, step, step over and run etc
> > are greyed out.
> > The timer peripheral window (in the debugger ) show the timer to be both
> > enabled and reset, so TC is stuck at 0, Timer0 is configured to
> > interrupt on MR0.
> > Which ever timer interrupts first causes the problem.
> >
> > isr's
> >
> > http://pastebin.com/9cVi5nAk
> >
> > I tried using the linker file you provide but I got some errors.
> >
> > linker error msgs, using crt.s with lpc2106_FLASH.ld
> > http://pastebin.com/i2ygBjxp
> >
> > Regards,
> > J
> >
> > It may not be a good idea to do your LCD updating in the ISR, unless these
> routines can handle a recursive call (ie. are reentrant). If these routines
> are also called from non-ISR code, the chances of one of them getting called
> while in the middle of itself is likely.
>
> Check to see if the VICVectAddr dummy write is handled in your ISR wrapper
> function. This is often where this is handled, so you don't need to put
> it in your handler function.
>
> Mike
>
I not quite sure how recursion would work in that context, LCD routines will only be called in the isr so -that should not be a problem?
Removing the VICTVEctAddr dummy write hasn't made noticeable difference.
Regards,
J
Reply by ●April 24, 20102010-04-24
--- In l..., "voltz56" wrote:
> I removed that but it didnt make difference as far as I can see. I did
> notice though I had forgotten to remove the __attribute__ ((interrupt))
> from the isr prototypes. I debugged a little with them removed and found
> that the program will only run to the end of the first isr to be called
> rather continually executing the first called...
>
> Regards,
> V
>
If you use the wrapper concept, you should remove the __attribute__ and use ordinary C functions.
Are you running this in hardware or only on a simulator? If you are running in hardware, what are you using to drive the capture input? Do you have a stripped down main().
I might be interested in playing with the ISRs but I don't want to have to build a complete system to do it. I have an Olimex 2106 board with a single input button.
http://www.sparkfun.com/commerce/product_info.php?products_id&9
Why don't you post the latest and greatest complete set of files after stripping out any non-essential stuff (LCD code, etc).
Richard
> I removed that but it didnt make difference as far as I can see. I did
> notice though I had forgotten to remove the __attribute__ ((interrupt))
> from the isr prototypes. I debugged a little with them removed and found
> that the program will only run to the end of the first isr to be called
> rather continually executing the first called...
>
> Regards,
> V
>
If you use the wrapper concept, you should remove the __attribute__ and use ordinary C functions.
Are you running this in hardware or only on a simulator? If you are running in hardware, what are you using to drive the capture input? Do you have a stripped down main().
I might be interested in playing with the ISRs but I don't want to have to build a complete system to do it. I have an Olimex 2106 board with a single input button.
http://www.sparkfun.com/commerce/product_info.php?products_id&9
Why don't you post the latest and greatest complete set of files after stripping out any non-essential stuff (LCD code, etc).
Richard
Reply by ●April 24, 20102010-04-24
--- In l..., "voltz56" wrote:
> --- In l..., Michael Anton wrote:
> > >
> > > I tried using the linker file you provide but I got some errors.
> > >
> > > linker error msgs, using crt.s with lpc2106_FLASH.ld
> > > http://pastebin.com/i2ygBjxp
> > >
> > > Regards,
> > > J
The linker is looking for the various vector targets:
void FIQ_Routine (void) {
while (1) ;
}
void SWI_Routine (void) {
while (1) ;
}
void UNDEF_Routine (void) {
while (1) ;
}
Richard
> --- In l..., Michael Anton wrote:
> > >
> > > I tried using the linker file you provide but I got some errors.
> > >
> > > linker error msgs, using crt.s with lpc2106_FLASH.ld
> > > http://pastebin.com/i2ygBjxp
> > >
> > > Regards,
> > > J
The linker is looking for the various vector targets:
void FIQ_Routine (void) {
while (1) ;
}
void SWI_Routine (void) {
while (1) ;
}
void UNDEF_Routine (void) {
while (1) ;
}
Richard
Reply by ●April 24, 20102010-04-24
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" wrote:
>
> > I removed that but it didnt make difference as far as I can see. I did
> > notice though I had forgotten to remove the __attribute__ ((interrupt))
> > from the isr prototypes. I debugged a little with them removed and found
> > that the program will only run to the end of the first isr to be called
> > rather continually executing the first called...
> >
> > Regards,
> > V
> > If you use the wrapper concept, you should remove the __attribute__ and use ordinary C functions.
>
> Are you running this in hardware or only on a simulator? If you are running in hardware, what are you using to drive the capture input? Do you have a stripped down main().
>
> I might be interested in playing with the ISRs but I don't want to have to build a complete system to do it. I have an Olimex 2106 board with a single input button.
> http://www.sparkfun.com/commerce/product_info.php?products_id&9
>
> Why don't you post the latest and greatest complete set of files after stripping out any non-essential stuff (LCD code, etc).
>
> Richard
>
Testing on both software and hardware. The output of a DAC is feed into the capture input. But you could use any squarewave, or just a switch etc..
Yes I have a stripped down main, the uart is polled for commands there, and the commands are then processed... That is basically all that's going on there.
Iv posted a zip file(in the temporary folder in the files section here) of an extremely stripped down version of the program
along with the linker and startup files. There is no code in the timer0 isr, you can put what ever you like in there for testing, but you could probably just remove everything to do with timer0 as I imagine it is the same problem with both all interrupts, Ill leave that up to you.
Thanks,
J
>
> --- In l..., "voltz56" wrote:
>
> > I removed that but it didnt make difference as far as I can see. I did
> > notice though I had forgotten to remove the __attribute__ ((interrupt))
> > from the isr prototypes. I debugged a little with them removed and found
> > that the program will only run to the end of the first isr to be called
> > rather continually executing the first called...
> >
> > Regards,
> > V
> > If you use the wrapper concept, you should remove the __attribute__ and use ordinary C functions.
>
> Are you running this in hardware or only on a simulator? If you are running in hardware, what are you using to drive the capture input? Do you have a stripped down main().
>
> I might be interested in playing with the ISRs but I don't want to have to build a complete system to do it. I have an Olimex 2106 board with a single input button.
> http://www.sparkfun.com/commerce/product_info.php?products_id&9
>
> Why don't you post the latest and greatest complete set of files after stripping out any non-essential stuff (LCD code, etc).
>
> Richard
>
Testing on both software and hardware. The output of a DAC is feed into the capture input. But you could use any squarewave, or just a switch etc..
Yes I have a stripped down main, the uart is polled for commands there, and the commands are then processed... That is basically all that's going on there.
Iv posted a zip file(in the temporary folder in the files section here) of an extremely stripped down version of the program
along with the linker and startup files. There is no code in the timer0 isr, you can put what ever you like in there for testing, but you could probably just remove everything to do with timer0 as I imagine it is the same problem with both all interrupts, Ill leave that up to you.
Thanks,
J
Reply by ●April 24, 20102010-04-24
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> > --- In l..., Michael Anton wrote:
>
> > > >
> > > > I tried using the linker file you provide but I got some errors.
> > > >
> > > > linker error msgs, using crt.s with lpc2106_FLASH.ld
> > > > http://pastebin.com/i2ygBjxp
> > > >
> > > > Regards,
> > > > J
>
> The linker is looking for the various vector targets:
>
> void FIQ_Routine (void) {
> while (1) ;
> }
>
> void SWI_Routine (void) {
> while (1) ;
> }
> void UNDEF_Routine (void) {
> while (1) ;
> }
>
> Richard
>
Ok, I seen that somewhere before. I tried adding those and using the crt.s and james lynches linker file, -everything compiled fine but the program wouldnt run at all in the debugger or hardware.
Regards,
V
>
> --- In l..., "voltz56" wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> > --- In l..., Michael Anton wrote:
>
> > > >
> > > > I tried using the linker file you provide but I got some errors.
> > > >
> > > > linker error msgs, using crt.s with lpc2106_FLASH.ld
> > > > http://pastebin.com/i2ygBjxp
> > > >
> > > > Regards,
> > > > J
>
> The linker is looking for the various vector targets:
>
> void FIQ_Routine (void) {
> while (1) ;
> }
>
> void SWI_Routine (void) {
> while (1) ;
> }
> void UNDEF_Routine (void) {
> while (1) ;
> }
>
> Richard
>
Ok, I seen that somewhere before. I tried adding those and using the crt.s and james lynches linker file, -everything compiled fine but the program wouldnt run at all in the debugger or hardware.
Regards,
V
