On Thu, 10 Aug 1995 11:18:36 CDT, "Jeff D. Pipkins" <pipkins@BANGATE.COMPAQ.COM>
 wrote:

> I'm wondering
> if any of you have any experience at all with the PIC problem
> that is written about in the fine print footnote on page 3 of
> appnote AN556.  It says that if an "interrupt occurs just before
> the 'movwf PCL' instruction, then the [...] new[ly] computed PC will
> be INCREMENTED and saved on the stack (as the return from interrupt
> address [...] On return from the interrupt the program will go to
> the intended offset of the table PLUS ONE.  This is a very
> undesirable result, so interrupts must be disabled during a
> table read operation." [emphases mine]

Jeff goes on to write that he was unable to reproduce this problem when using
timer interrupts, but that he wasn't sure if the problem occurs with other
unsychronized interrupts (such as external interrupt sources).

I inquired about this problem at the recent Microchip seminar, and the speaker
suggested that the application note _might_ be in error, but he wasn't sure.

Rich Ottosen has experimented with this using an external interrupt from a
signal generator using 60 Hz into a VCO (to try to vary the phase of the
external interrupt with respect to the PIC's internal timing).  He was unable
to reproduce the problem with a PIC16C84 in this setup.  He has provided me
with a copy of his test program which I will add to my web page when I get
back from vacation next week.

IMHO, someone at Microchip must have encountered some sort of interrupt
problem and reached an erroneous conclusion as to the cause.

> Disabling interrupts every time you do a table read is just downright
> unacceptable for lots of applications (including mine, of course).

Agreed!  Rich points out that the re-enabling of the interrupts is the
hard part, since it has to be done in every code path that the table
takes.  Not too bad for a table read, since you just have to reenable
interrupts from every place that calls the table.  If you have time and
stack levels to spare, you can just have a subroutine that disables interrupts,
calls the jump table, and reenables interrupts.  For a jump table it is more
of a problem since every jump target has to reenable them.

This would be even more of a problem since it is difficult to disable
interrupts using the GIE (global interrupt enable) bit, as described in
Microchip AN 576.  For most purposes it is possible to disable a specific
interrupt using its enable bit.  For the 16C74, for example, you can often
use the PEIE bit in the INTCON register.

Fortunately it appears that none of this interrupt silliness is actually
necessary, since I've yet to hear of anyone reproducing the alleged problem.

Cheers,
Eric
http://www.telebit.com/~eric/pic/