Here is the assembly code generated for the first part of the interrupt
handler:


0014fa   cfe7     MOVFF     0xfe7,0xfe6    void Interrupt_Handler(void) {
0014fc   ffe6

0014fe   cfe9     MOVFF     0xfe9,0xfe6

001500   ffe6

001502   cfea     MOVFF     0xfea,0xfe6

001504   ffe6

001506   cfd9     MOVFF     0xfd9,0xfe6

001508   ffe6
00150a   cfe1     MOVFF     0xfe1,0xfd9

00150c   ffd9

00150e   0e01     MOVLW     0x1

001510   26e1     ADDWF     0xe1,0x1,0x0

                                             unsigned char TEMP;
001512   a4f2     BTFSS     0xf2,0x2,0x0     if (INTCONbits.TMR0IF) {
The registers for the 18C452 are:

FE7=INDF1
FE6=POSTINC1
FE9=FSR0L
FEA=FSR0H
FD9=FSR2L
FE1=FSR1L

Upon further testing and analysis, it seems that I may have misstated the
original problem.  I don't know if it is just FSR0 getting corrupted, or if
it is more than that.  I originally thought that the index term (ID) was
being corrupted, but it looks like the entire data stack is behaving funny.

I should also note that the procedure that is being interrupted is meant to
be reentrant.  This is the reason I found this "bug" in the first place.
One of the interrupts that can interrupt the procedure is the serial data
interrupt.  If that happens, the same procedure is called by the serial
data interrupt handler  (with a different value for ID).

Thanks for the help ,
Jeff.

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu