Paul,

Many thanks! Not declaring the isr as "__attribute ((interrupt ("IRQ" )
))" did the trick!!!!

Well, did not had any board support package cause I unfortunately don't
have any board supported by Crossworks.

Anyways, I would not have expected that isr's with crossworks work like
standard routines. Cool.... Too bad I learned so late about it, but
better now than never. Again, thanks! Will look at the documentation you
mentioned :-)

Markus

Paul Curtis schrieb:
>
> Hi,
>
> > I created a new project with the Project Wizzard to be on the save side
> > and added the three small source files (emac.c emactest.c and crc32.c).
> > Crossworks now included VIC controll code. I'm now back to using the
> > fuctions you suggested (see below). Unfortunately I'm also back to the
> > problems....
> >
> > I meanwhile spent close to two weeks on getting this code to work
> > reliable. Lacking experinece with Crossworks and the LPC2378 I first
> > misinterpreted a lot of things, but I now can say that as soon as the
> > isr routine GETs called, things go highwire on return from the isr. I
> > thus wonder what could go wrong by using
> >
> > ctl_set_isr( );
> > ctl_global_interrupts_enable();
> > ctl_unmask_isr( );
> >
> > to setup the isr routine and enable the interruts and by using an isr
> > routine declared as
> >
> > extern __attribute ((interrupt ("IRQ" ) )) void EMACHandler( void );
>
> Nope. Don't use the attribute--you can plug *any* function into the
> handling code using ctl_set_isr, but don't plug in "naked" interrupt
> handler!
>
> > so badly that on return from the isr, local variables in the fuction
> > that was interrupted (actually a simple sending loop) point to the
> > nirvana?
>
> Of course. The only thing you should pass in is a function. The CTL
> functions take care of housekeeping and managing the VIC.
>
> > I'm really new to the ARM and Crossworks, I'm not lazy and willing to
> > work to get this going, but it seems a truly steep entry here. Is there
> > a way I can get help with that relatively small sample?
>
> We ship examples for many boards, including interrupt examples. Perhaps
> you've not read the documentation in the board support packages? :-(
>
> > Can I send the
> > code (well, did that alredy with no reply at all)? I'm willing to pay
> > for a solution if needed, cause I'm starting to get under pressure from
> > all sides. Are you so absolutely sure that nothing could be wrong with
> > the isr dealing code in Crossworks? What do you suggest I can do to
> > finally get over all this and move on?
>
> Absolutely sure nothing is wrong. 100%. But I'm also 100% sure that you've
> not read the documentation and you've tried with a large project to begin
> with. I would suggest you take a look at some of the example projects we
> provide for the 2368 and 2468 boards we support.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
>
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
> Start a New Thread

Hi,

> I created a new project with the Project Wizzard to be on the save side
> and added the three small source files (emac.c emactest.c and crc32.c).
> Crossworks now included VIC controll code. I'm now back to using the
> fuctions you suggested (see below). Unfortunately I'm also back to the
> problems....
>
> I meanwhile spent close to two weeks on getting this code to work
> reliable. Lacking experinece with Crossworks and the LPC2378 I first
> misinterpreted a lot of things, but I now can say that as soon as the
> isr routine GETs called, things go highwire on return from the isr. I
> thus wonder what could go wrong by using
>
> ctl_set_isr( );
> ctl_global_interrupts_enable();
> ctl_unmask_isr( );
>
> to setup the isr routine and enable the interruts and by using an isr
> routine declared as
>
> extern __attribute ((interrupt ("IRQ" ) )) void EMACHandler( void );

Nope. Don't use the attribute--you can plug *any* function into the
handling code using ctl_set_isr, but don't plug in "naked" interrupt
handler!

> so badly that on return from the isr, local variables in the fuction
> that was interrupted (actually a simple sending loop) point to the
> nirvana?

Of course. The only thing you should pass in is a function. The CTL
functions take care of housekeeping and managing the VIC.

> I'm really new to the ARM and Crossworks, I'm not lazy and willing to
> work to get this going, but it seems a truly steep entry here. Is there
> a way I can get help with that relatively small sample?

We ship examples for many boards, including interrupt examples. Perhaps
you've not read the documentation in the board support packages? :-(

> Can I send the
> code (well, did that alredy with no reply at all)? I'm willing to pay
> for a solution if needed, cause I'm starting to get under pressure from
> all sides. Are you so absolutely sure that nothing could be wrong with
> the isr dealing code in Crossworks? What do you suggest I can do to
> finally get over all this and move on?

Absolutely sure nothing is wrong. 100%. But I'm also 100% sure that you've
not read the documentation and you've tried with a large project to begin
with. I would suggest you take a look at some of the example projects we
provide for the 2368 and 2468 boards we support.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread