Re: [avr-gcc-list] avr-gcc adding 'cli's in function prologues...

[Ludovic COURTES]

Hi !

I finally found what was going wrong with gcc's prologue and epilogue.
As i wrote before (see below), avr-gcc uses Y (r29:r28) to store stack
pointer and then decrement it in order to reserve some space for local
variables in SRAM (this is done in function prologue) and then increment
it with the same value to restore original SP (this is done in epilogue).

The problem is that gcc doesn't save Y at the end of prologue. Therefore,
if your code uses theses registers and modify them, then the ret instruction
won't do what you want it to (as the SP will be wrong) !
I fixed it just by adding a "push y" and a "pop y" at the beginning and
at the end of my code.


> Sorry, just hanging the CPU is not enough information.  Usually my bizarre
> problems are solved by making the stacks bigger.  Oh, to have a real ICE
> and to be able to set breakpoints on the end of my stacks...  The other
> typical problem is not having the right set of interrupt vectors (why did
> Atmel choose to shuffle vectors with each chip!!!)
> 
> Cheers!
> 
> ----- Original Message -----
> From: "Ludovic COURTES" <address@hidden>
> To: "Larry Barello" <address@hidden>
> Sent: Tuesday, May 15, 2001 1:27 AM
> Subject: Re: [avr-gcc-list] avr-gcc adding 'cli's in function prologues...
> 
> 
> > Hi !
> >
> > > Which version?  Could you give me an example of a function that has the
> > > errant CLI in it?
> >
> > In fact, gcc increases SP to create a stack frame to store local
> variables
> > in. The 'cli' appears just before it increases the 16-bit stack pointer,
> > so that it can't be a problem as no interrupt handler can be called in
> between
> > the increasing of the low and hi byte.
> >
> > The resulting code is something like that :
> > in __tmp_reg__,__SREG__
> > in r28, __SP_L__
> > in r29, __SP_H__
> > subi r28,lo8(8) /* 8 byte stack frame */
> > sbci r29,hi8(8)
> > cli
> > out __SP_L__,r28
> > out __SP_H__,r29
> > out __SREG__,__tmp_reg__ /* restores interrupts */
> >
> > In fact, interrupts are re-enabled by restoring the SREG.
> > Therefore, this shouldn't be a problem...
> > But anyway, I am still having problem with some functions hanging the MCU
> > without doing anything particular (if you have any idea of what could
> > make it, i'm interested in it !)...
> >
> 
> 

-- 
Ludovic Courtes
  University of Technology of Belfort-Montbeliard
  Unitec (UTBM's students Robotics Club)