--- In l..., "voltz56" wrote:
>
> 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
>
I hacked over your code but it was substantially correct, given that I used MY
header, startup and linker files.
I didn't have your device definition header file so I used mine and
#defined your symbols to mine.
I added 3 LED outputs so I could watch the thing on a scope and an LED
I changed the frequency calculation because I have a 14.745600 MHz crystal.
I changed your two global counter variables to volatile unsigned int.
But the biggest and most important change is in the timer1 interrupt handler. I
changed the way interrupts are ack'ed such that an IR bit is only cleared
if that specific IR is actually handled. You'll see it.
Anyway, I have the board sitting here and it is running.
I'm no good with CodeSourcery (I don't know how to use it even though
I have it on my Win7 box), So, I went with GNUARM and my Linux box. The reason
I didn't use CrossWorks is that my 2106 doesn't work with JTAG (I
think I messed up the chip) and I don't like my alternatives for ISP device
programming under Win7 (FlashMagic, I suppose).
Richard
Richard
LPC2106 GNU CodeSourcery Toolchain: How to enable nested interrupts
Started by ●April 22, 2010
Reply by ●April 24, 20102010-04-24
Reply by ●April 24, 20102010-04-24
Reply by ●April 24, 20102010-04-24
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" wrote:
> > > 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
> > I hacked over your code but it was substantially correct, given that I used MY header, startup and linker files.
>
> I didn't have your device definition header file so I used mine and #defined your symbols to mine.
>
> I added 3 LED outputs so I could watch the thing on a scope and an LED
>
> I changed the frequency calculation because I have a 14.745600 MHz crystal.
>
> I changed your two global counter variables to volatile unsigned int.
>
> But the biggest and most important change is in the timer1 interrupt handler. I changed the way interrupts are ack'ed such that an IR bit is only cleared if that specific IR is actually handled. You'll see it.
>
> Anyway, I have the board sitting here and it is running.
>
> I'm no good with CodeSourcery (I don't know how to use it even though I have it on my Win7 box), So, I went with GNUARM and my Linux box. The reason I didn't use CrossWorks is that my 2106 doesn't work with JTAG (I think I messed up the chip) and I don't like my alternatives for ISP device programming under Win7 (FlashMagic, I suppose).
>
> Richard
>
> Richard
>
Firstly thanks for taking the time to look this and sorry for not uploading the device definition file, I ment to...
I just made all of those changes to my code, but the program wont run at all in the software debugger or hardware. I also tryed adding the c file that you updated to my project and that wont run either. Im starting to think this must be a problem with the project settings in keil.
Thanks again,
J
>
> --- In l..., "voltz56" wrote:
> > > 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
> > I hacked over your code but it was substantially correct, given that I used MY header, startup and linker files.
>
> I didn't have your device definition header file so I used mine and #defined your symbols to mine.
>
> I added 3 LED outputs so I could watch the thing on a scope and an LED
>
> I changed the frequency calculation because I have a 14.745600 MHz crystal.
>
> I changed your two global counter variables to volatile unsigned int.
>
> But the biggest and most important change is in the timer1 interrupt handler. I changed the way interrupts are ack'ed such that an IR bit is only cleared if that specific IR is actually handled. You'll see it.
>
> Anyway, I have the board sitting here and it is running.
>
> I'm no good with CodeSourcery (I don't know how to use it even though I have it on my Win7 box), So, I went with GNUARM and my Linux box. The reason I didn't use CrossWorks is that my 2106 doesn't work with JTAG (I think I messed up the chip) and I don't like my alternatives for ISP device programming under Win7 (FlashMagic, I suppose).
>
> Richard
>
> Richard
>
Firstly thanks for taking the time to look this and sorry for not uploading the device definition file, I ment to...
I just made all of those changes to my code, but the program wont run at all in the software debugger or hardware. I also tryed adding the c file that you updated to my project and that wont run either. Im starting to think this must be a problem with the project settings in keil.
Thanks again,
J
Reply by ●April 24, 20102010-04-24
--- In l..., "voltz56" wrote:
> Firstly thanks for taking the time to look this and sorry for not uploading the device definition file, I ment to...
>
> I just made all of those changes to my code, but the program wont run at all in the software debugger or hardware. I also tryed adding the c file that you updated to my project and that wont run either. Im starting to think this must be a problem with the project settings in keil.
>
> Thanks again,
> J
>
Integrated systems want to 'help' you. They have any number of check boxes and such that are used to configure the project.
You might try to install YAGARTO and use the files I supplied. You will need to change the Makefile because I specify the path for the various GNU executables. See below...
I have WinARM on my Win7 (x64) box and I just rebuilt the .hex file from the command line. I had to modify the Makefile to add /bin/ to the end of the LOCATION macro, add # in front of the LOCATION MACRO to comment it out and then delete /bin/ from all of the individual executable paths. That /bin/ should always have been part of the LOCATION macro. Duh!
I'm not sure but I think the WinARM version is VERY old! YAGARTO is quite new.
I don't have lpc21isp on the Win7 box (does it work?) nor do I have FlashMagic. I'll just have to assume that the WinARM version of the code works.
Since you have the CodeSourcery version of the GNU tools, you can change the name of the executables arm-elf versus arm-eabi, I believe, and try to compile from the command line. Just change the macros in the Makefile. Once you produce a hex file, you should be able to use whatever device programming method you have available.
I don't know if your board uses IO pins 5-7. If they are available for testing, why not try the .hex file I provided. Sure, the crystal frequency and related calcs will be off but so what? I jumped pins 7 and 10 to get a capture input.
Richard
> Firstly thanks for taking the time to look this and sorry for not uploading the device definition file, I ment to...
>
> I just made all of those changes to my code, but the program wont run at all in the software debugger or hardware. I also tryed adding the c file that you updated to my project and that wont run either. Im starting to think this must be a problem with the project settings in keil.
>
> Thanks again,
> J
>
Integrated systems want to 'help' you. They have any number of check boxes and such that are used to configure the project.
You might try to install YAGARTO and use the files I supplied. You will need to change the Makefile because I specify the path for the various GNU executables. See below...
I have WinARM on my Win7 (x64) box and I just rebuilt the .hex file from the command line. I had to modify the Makefile to add /bin/ to the end of the LOCATION macro, add # in front of the LOCATION MACRO to comment it out and then delete /bin/ from all of the individual executable paths. That /bin/ should always have been part of the LOCATION macro. Duh!
I'm not sure but I think the WinARM version is VERY old! YAGARTO is quite new.
I don't have lpc21isp on the Win7 box (does it work?) nor do I have FlashMagic. I'll just have to assume that the WinARM version of the code works.
Since you have the CodeSourcery version of the GNU tools, you can change the name of the executables arm-elf versus arm-eabi, I believe, and try to compile from the command line. Just change the macros in the Makefile. Once you produce a hex file, you should be able to use whatever device programming method you have available.
I don't know if your board uses IO pins 5-7. If they are available for testing, why not try the .hex file I provided. Sure, the crystal frequency and related calcs will be off but so what? I jumped pins 7 and 10 to get a capture input.
Richard
Reply by ●April 24, 20102010-04-24
--- In l..., "rtstofer" wrote:
I stand corrected, I do have FlashMagic on my Win7 box. The WinARM version I built using the revised Makefile functions well. I put the Makefile in the Temporary folder.
WinARM is on my path and the Makefile reflects this.
FlashMagic works perfectly on Win7 (x64).
I didn't post the revised .hex file, there's no point. But it is worth pointing out that it is somewhat shorter than the GNUARM version. Hm... Different toolchain versions.
Richard
I stand corrected, I do have FlashMagic on my Win7 box. The WinARM version I built using the revised Makefile functions well. I put the Makefile in the Temporary folder.
WinARM is on my path and the Makefile reflects this.
FlashMagic works perfectly on Win7 (x64).
I didn't post the revised .hex file, there's no point. But it is worth pointing out that it is somewhat shorter than the GNUARM version. Hm... Different toolchain versions.
Richard
Reply by ●April 24, 20102010-04-24
> -----Original Message-----
> From: l...
> [mailto:l...]On Behalf
> Of voltz56
> Sent: Saturday, April 24, 2010 3:57 AM
> To: l...
> Subject: [lpc2000] Re: LPC2106 GNU CodeSourcery Toolchain:
> How to enable
> nested interrupts
>
> > 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
>
Correct, if the LCD code is only called from an (one) ISR, you
will be fine. But if you allow nested interrupts an call it
from another ISR, or main() you will have recursion problems.
Mike
> From: l...
> [mailto:l...]On Behalf
> Of voltz56
> Sent: Saturday, April 24, 2010 3:57 AM
> To: l...
> Subject: [lpc2000] Re: LPC2106 GNU CodeSourcery Toolchain:
> How to enable
> nested interrupts
>
> > 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
>
Correct, if the LCD code is only called from an (one) ISR, you
will be fine. But if you allow nested interrupts an call it
from another ISR, or main() you will have recursion problems.
Mike
Reply by ●April 25, 20102010-04-25
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" wrote:
>
> > Firstly thanks for taking the time to look this and sorry for not uploading the device definition file, I ment to...
> >
> > I just made all of those changes to my code, but the program wont run at all in the software debugger or hardware. I also tryed adding the c file that you updated to my project and that wont run either. Im starting to think this must be a problem with the project settings in keil.
> >
> > Thanks again,
> > J
> > Integrated systems want to 'help' you. They have any number of check boxes and such that are used to configure the project.
>
> You might try to install YAGARTO and use the files I supplied. You will need to change the Makefile because I specify the path for the various GNU executables. See below...
>
> I have WinARM on my Win7 (x64) box and I just rebuilt the .hex file from the command line. I had to modify the Makefile to add /bin/ to the end of the LOCATION macro, add # in front of the LOCATION MACRO to comment it out and then delete /bin/ from all of the individual executable paths. That /bin/ should always have been part of the LOCATION macro. Duh!
>
> I'm not sure but I think the WinARM version is VERY old! YAGARTO is quite new.
>
> I don't have lpc21isp on the Win7 box (does it work?) nor do I have FlashMagic. I'll just have to assume that the WinARM version of the code works.
>
> Since you have the CodeSourcery version of the GNU tools, you can change the name of the executables arm-elf versus arm-eabi, I believe, and try to compile from the command line. Just change the macros in the Makefile. Once you produce a hex file, you should be able to use whatever device programming method you have available.
>
> I don't know if your board uses IO pins 5-7. If they are available for testing, why not try the .hex file I provided. Sure, the crystal frequency and related calcs will be off but so what? I jumped pins 7 and 10 to get a capture input.
>
> Richard
>
I tried your hex file and it works fine.
I don't have time to spend another day at this( at the moment)( I cant imagine it will be a quick process) so I think Ill leave changing my development environ for another time, something that I will definitely do, keil is driving me nuts as far as arm dev goes, (Iv had no problems though with keil and 8051).
BTW I use Philips lpc2000 download utility which works fine on vista x64, Ive never been able to get flash magic to work but I haven't really tried that hard either.
Thanks again for all your help,
J
>
> --- In l..., "voltz56" wrote:
>
> > Firstly thanks for taking the time to look this and sorry for not uploading the device definition file, I ment to...
> >
> > I just made all of those changes to my code, but the program wont run at all in the software debugger or hardware. I also tryed adding the c file that you updated to my project and that wont run either. Im starting to think this must be a problem with the project settings in keil.
> >
> > Thanks again,
> > J
> > Integrated systems want to 'help' you. They have any number of check boxes and such that are used to configure the project.
>
> You might try to install YAGARTO and use the files I supplied. You will need to change the Makefile because I specify the path for the various GNU executables. See below...
>
> I have WinARM on my Win7 (x64) box and I just rebuilt the .hex file from the command line. I had to modify the Makefile to add /bin/ to the end of the LOCATION macro, add # in front of the LOCATION MACRO to comment it out and then delete /bin/ from all of the individual executable paths. That /bin/ should always have been part of the LOCATION macro. Duh!
>
> I'm not sure but I think the WinARM version is VERY old! YAGARTO is quite new.
>
> I don't have lpc21isp on the Win7 box (does it work?) nor do I have FlashMagic. I'll just have to assume that the WinARM version of the code works.
>
> Since you have the CodeSourcery version of the GNU tools, you can change the name of the executables arm-elf versus arm-eabi, I believe, and try to compile from the command line. Just change the macros in the Makefile. Once you produce a hex file, you should be able to use whatever device programming method you have available.
>
> I don't know if your board uses IO pins 5-7. If they are available for testing, why not try the .hex file I provided. Sure, the crystal frequency and related calcs will be off but so what? I jumped pins 7 and 10 to get a capture input.
>
> Richard
>
I tried your hex file and it works fine.
I don't have time to spend another day at this( at the moment)( I cant imagine it will be a quick process) so I think Ill leave changing my development environ for another time, something that I will definitely do, keil is driving me nuts as far as arm dev goes, (Iv had no problems though with keil and 8051).
BTW I use Philips lpc2000 download utility which works fine on vista x64, Ive never been able to get flash magic to work but I haven't really tried that hard either.
Thanks again for all your help,
J
Reply by ●April 25, 20102010-04-25
--- In l..., "Michael Anton" wrote:
>
> > -----Original Message-----
> > From: l...
> > [mailto:l...]On Behalf
> > Of voltz56
> > Sent: Saturday, April 24, 2010 3:57 AM
> > To: l...
> > Subject: [lpc2000] Re: LPC2106 GNU CodeSourcery Toolchain:
> > How to enable
> > nested interrupts
> >
>
>
> > > 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
> > Correct, if the LCD code is only called from an (one) ISR, you
> will be fine. But if you allow nested interrupts an call it
> from another ISR, or main() you will have recursion problems.
>
> Mike
>
Thanks for clearing that up.
Regards,
J
>
> > -----Original Message-----
> > From: l...
> > [mailto:l...]On Behalf
> > Of voltz56
> > Sent: Saturday, April 24, 2010 3:57 AM
> > To: l...
> > Subject: [lpc2000] Re: LPC2106 GNU CodeSourcery Toolchain:
> > How to enable
> > nested interrupts
> >
>
>
> > > 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
> > Correct, if the LCD code is only called from an (one) ISR, you
> will be fine. But if you allow nested interrupts an call it
> from another ISR, or main() you will have recursion problems.
>
> Mike
>
Thanks for clearing that up.
Regards,
J
