Lpc2000

Hello folks,
I noticed something weird about GCC-3.3.1 compiler. When calling a 
function (here called SomeFunction) with pointer among arguments list 
from ISR, SomeFunction does not return to the right place. I checked 
out in *.lst file, that compiler makes place for variable val (local 
in ISR, pointed by pData in SomeFunction) out of ISR's frame on the 
stack and exactly, where SomeFunction stores it's Link Register! 
Writing to the pointed location (*pData=2) overrides SomeFunction's LR 
and program crashes. I also noticed, that in GCC-4.0.1 all works well 
- compiler makes place for ISR's locals in ISR's frame, not out of it.

Could it be GCC-3.3.1 compiler's error?


Here some C code:

//*******************************
// EINT0 interrupt routine
//*******************************
void EINT0ISR(void)
{
	unsigned char val;
	
	EXTINT=0x01;	//Clear EINT0 interrupt flag

	SomeFunction(a, b, &val);

      //doing something with val
      ......

	VICVectAddr=0x00000000;
}

//*******************************
// SomeFunction
//*******************************
SomeFunction(const unsigned int x, const unsigned char y, unsigned 
char *pByte)
{
      .....

      //this causes SomeFunction not to return properly
      //without this the function return is OK
	*pByte=2;

      ......
}


Regards,Arek

---- Original Message ----

From: "arrek_x" <hal9900@...>
To: <lpc2000@yahoogroups.com>
Sent: Saturday, February 25, 2006 12:24 AM
Subject: [lpc2000] GCC-3.3.1 and nested function call in ISR - compiler
ERROR???

> Hello folks,
> I noticed something weird about GCC-3.3.1 compiler. When calling a
> function (here called SomeFunction) with pointer among arguments list
> from ISR, SomeFunction does not return to the right place. I checked
> out in *.lst file, that compiler makes place for variable val (local
> in ISR, pointed by pData in SomeFunction) out of ISR's frame on the
> stack and exactly, where SomeFunction stores it's Link Register!
> Writing to the pointed location (*pData=2) overrides SomeFunction's LR
> and program crashes. I also noticed, that in GCC-4.0.1 all works well
> - compiler makes place for ISR's locals in ISR's frame, not out of it.
>
> Could it be GCC-3.3.1 compiler's error?
>
>
> Here some C code:
>
> //*******************************
> // EINT0 interrupt routine
> //*******************************
> void EINT0ISR(void)
> {
> unsigned char val;
>
> EXTINT=0x01; //Clear EINT0 interrupt flag
>
> SomeFunction(a, b, &val);
>
>      //doing something with val
>      ......
>
> VICVectAddr=0x00000000;
> }
>
> //*******************************
> // SomeFunction
> //*******************************
> SomeFunction(const unsigned int x, const unsigned char y, unsigned
> char *pByte)
> {
>      .....
>
>      //this causes SomeFunction not to return properly
>      //without this the function return is OK
> *pByte=2;
>
>      ......
> }

Are you using the compiler's interrupt entry/exit code, such as
void EINT0ISR(void) __attribute__ ((interrupt("IRQ")));
?
GCC 3.3 generates incorrect interrupt entry/exit code, and that is most 
likely what you see here.  It is fixed in GCC 3.4 and newer.

Karl Olsen

--- In lpc2000@yahoogroups.com, "Karl Olsen" <kro@...> wrote:
> Are you using the compiler's interrupt entry/exit code, such as
> void EINT0ISR(void) __attribute__ ((interrupt("IRQ")));
> ?

yes

> GCC 3.3 generates incorrect interrupt entry/exit code, and that is 
most 
> likely what you see here.  It is fixed in GCC 3.4 and newer.
> 
> Karl Olsen
>

You're surely right, I've read about this problem earlier on this 
group and it is probably the reason. But the reason of posting this 
topis was, that I have noticed, that asm entry code seems to be the 
same for 3.3 and 4.0 gcc versions. The difference is location of some 
ISR's local variables on the stack in place, where another function's 
frame is situated. But probalby it is related to an error you have 
described.

Arek

I don't know if the problem is fixed with GCC 3.4 but surely is not in
version 4.0.2.
I installed the GNUARM toolchain 4.0.2 to solve these problems but
experienced the same type of errors as in 3.0.1.
For me the best thing to do is to encapsulate the C interrupt handler
in an assembly code wrapper avoiding the use of "IRQ" attribute.

Carlo

--- In lpc2000@yahoogroups.com, "c.barbaro" <c.barbaro@...> wrote:
>
> I don't know if the problem is fixed with GCC 3.4 but surely is not 
in
> version 4.0.2.
> I installed the GNUARM toolchain 4.0.2 to solve these problems but
> experienced the same type of errors as in 3.0.1.
> For me the best thing to do is to encapsulate the C interrupt 
handler
> in an assembly code wrapper avoiding the use of "IRQ" attribute.
> 
> Carlo
>

Like they say, "if you want something to be done well, do it yourself"
 :). But in my specific example, with GCC-4.0.1 I didn't meet problem 
I desribed. It's possible, that the problem hasn't been complitely 
solved, but I hope it has.
In my case, with GCC-3.3.1 compiler puts ISR's local variable (val) 45 
bytes below ISR's Frame Pointer (on teh stack), where ISR's frame's 
length equals 40 bytes.
With GCC-4.0.1 offset equals 37 bytes instead 45 (ISR's frame lengt 
still equals 40 bytes).

Arek