On Mon, 11 Mar 2002 19:38:42 -0600, michael brown wrote:

>> The only thing I can think of is something to do with the interrrupt
>> happening at a particular point and the PC going screwy.  But I am
>otherwise
>> baffled!
>
>Bingo, I would look into this.  You are probably getting an interrupt =
when
>you are switched to BANK1 in main level and then the interrupt routine =
is
>returning with BANK0 selected.  Your main level code then stomps the =
wrong
>configuration register.  Your interrupt routine may be setting the BANK =
and
>not restoring it to the one that was selected when the interrupt routine=
 was
>entered.  The most important thing with interrupts is that you have to =
put
>absolutely everything back like it was when the interrupt occured.  The
>microchip docs make a big deal out of STATUS and W, but they don't =
really
>mention about saving FSR, the current BANKx and a few other things you =
might
>be using. =20


I think that the reason Microchip is so explicit about STATUS and W is
that's it's really tough to do *anything* without affecting them in
some way. If your interrupt routine modifies FSR, then, obviously, it
needs to be saved and restored but saving and restoring STATUS will
take care of your bank bits, won't it?


Regards, Bob



>Go thru your main level code and try to imagine an interrupt
>occurring between any two instructions, eventually that is what happens =
at
>run time.

It might be more productive to first re-check the interrupt routine
itself to ensure that it isn't modifying something that it's not
preserving across interrupts. Anything used in the interrupt routine
is suspect but can be desk-checked for being properly preserved across
the call.


Regards, Bob

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body