Hello to all of you PICers and grinners out there.  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]

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

Since the only kind of interrupt I'm allowing is the timer, I had a
better idea (see following listing).  To make this idea work, I
needed to know the exact place where the "window" of error could
occur.  Strangely enough, I was not able to reproduce the problem at
all, not even once, even though I wrote several test programs that
should have encountered it.  I'm guessing that the problem doesn't
occur with the timer interrupt because of the place that the timer
interrupt sampling occurs within the scheme of an instruction cycle.
I wish I had more detailed documentation on the ordering of events
within an entire instruction cycle.

Anyway, the code illustrates the situation better, so here it is.
Please let me know if you have any additional information.

Thanks, and here's the code:

             ; Now decode the opcode and execute!
             ;
             ; See Appnote AN556 on table look-ups.
             ; If an interrupt happens when the PCL is loaded,
             ; Then the interrupt return address will be incorrect.
             ; I do NOT want to disable interrupts here, for
             ; several reasons:

             [ censored -- sorry ]

             ; Another workaround is to multiply the state by 2 and
             ; to provide a nop entry before each goto in the table.
             ; I'd like to avoid that.
             ;
             ; My solution is based on the fact that there's only
             ; one kind of interrupt in this system, and that's
             ; the timer.  By looking at the value of the timer,
             ; I can predict when the timer will occur.  It's
             ; convenient that the timer is setup to increment once
             ; with each instruction.  I just check the timer
             ; counter to see if the interrupt is going to happen
             ; at just the wrong time, and if so, I simply delay
             ; for one instruction cycle!
             ;
             ; Further note: In an effort to determine the exact
             ; timer value at which the problem would occur, I was
             ; not able to reproduce the problem at all, with any
             ; timer value!  So I've commented it out for now until
             ; I can gather more info.

            ;movlw        0xC + 3  ;C   ; GUESS! Need to figure out exact
 number!!!
            ;addwf        TMR0,w   ;B
            ;btfsc        STATUS,C ;A   ; Will TMR0 overflow at movwf PCL?
            ;goto         $+1      ;9, one extra wait cycle iff executed

             movlw        HIGH opcd_table  ;8
             movwf        PCLATH           ;7
             movf         cmd1,w           ;6
             andlw        0x0F             ;5 isolate opcode bits
             addlw        LOW opcd_table   ;4 compute jump, set carry
             btfsc        STATUS,C         ;3 does table cross 256w page?
             incf         PCLATH           ;2 if so, point at next page
             movwf        PCL              ;1,0 jump: NO INTERRUPTS HERE
opcd_table:
             goto         opcd_0000
             goto         opcd_0001
             goto         opcd_0010
             goto         opcd_0011
             [etc...]


=================== Reply to Pipkins@bangate.compaq.com =====================
Jeff D. Pipkins
Lead, Communications VP, Lone Star Statesmen Barbershop Chorus
This msg contains only my personal opinions; use them only at your own risk.