Re: [avr-gcc-list] assembly-c mix and interrupts

[Ruud Vlaming]

Your description is rather vague, but in any case i would say that at
interrupt you should save everything you make use of in your routine.
It seems to me that it is very unlikely that you do not make 
(indirect) use of the SREG. Thus you have to save (and restore!) it. 
From experience i can say that occasionally corrupted SREG may
lead to very strange behaviour.

The general rule is: the complete state of the device should be
equal before and after the interrupt. This includes global variables
and special registers you may use.

And, when you add instructions to save SREG, make sure you save the
register you use to save the SREG first, and have no instructions that
may damage the SREG before it is saved. 

Good luck!

On Thursday 19 November 2009, darkschine wrote:
> 
> Before I continue, I would like to suggest a resolution to my problem. I am
> using the ATmega328P
> My assembly code follows a standard that ALL registers used are pushed and
> popped from the stack. However, my assembly code does NOT store the SREG.
> Could this be causing my problems?
> 
> I am coming across a problem in a fairly large project where the system
> seems to display incorrect data on the LCD screen and eventually reset
> itself. Other symptoms include displaying incorrect data when string
> constants are transfered to the LCD. The worst case of the problem has been
> uninitiated transfer to a part in the program requiring text input from the
> user. The text input also automatically accepts the character selected first
> by default.
> 
> The problem has proved very difficult to debug since modifying the code can
> cause unpredictable behaviour of the error.
> 
> I believe that the problem first appeared as a global variable changing its
> value for no reason. The problem was corrected by declaring the global
> variable as static which I then considered to be the standard, but am now
> thinking it only masked the problem by storing the variable in a different
> location or modifying the compilation structure.
> 
> Now, all functions seem to be operating correctly and all unit tests pass,
> until interrupt routines are enabled.
> 
> Can anyone provide any insight into this problem or provide some debugging
> techniques to help identify it?