--- 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

An Engineer's Guide to the LPC2100 Series

--- 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

> -----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

--- 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

--- 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

--- 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

Oh, and I posted ARM2106SigGen.zip to the Temporary folder.

Richard

--- 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

--- 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..., "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