Magic nop's and a baffling program bug

I've been working on a 16F1703 assembly language program, and it stopped working after I made made a small revision that moved 7 instructions to a different location. I couldn't see any reason for this, but reversed the change, and everything was fine again. After more experimentation, I determined that I could turn the problem on or off by inserting or removing 4 nop instructions near the place where I'd made the original revision. So, then I decided to move the nop's to different locations in the program. The result was that if the nop's were located anywhere before the revised code, then everything worked fine. If I moved them to any place after the revised code, or left them out completely, then the program failed.
This looks to me like some kind of page boundary problem, but the 16F1703 has only 2048 words of memory, which from my understanding, means that PCLATH should never have to be loaded with anything other than zero. The other memory boundary problem could be a table of computed goto's or calls. I do have some of these, but they all occur at the beginning of the program and none of them cross a 256 word boundary. The program length is 1613 words. The area of the program where the revision was made is around address 0x0200, which is suspicious, but I can't see anything amiss there.

Am I completely misunderstanding the memory page boundary principles, or are there other possible issues that could be affected by a slight shift of the program?

BobW said:

means that PCLATH should never have to be loaded with anything other than zero.

Click to expand...

This is true for goto and call but PCL is only 8 bit and so it will contain other values than zero. Note that a call followed by a return will change PCLATH so computed gotos may go to the wrong page. Can you add a clrf PCLATH to your table code to see if that fixes it?

Mike.
Edit, ignore, wasn't thinking straight. Need morning coffee.

It turns out that the programmer (me, not the PICkit) is an idiot. I have a register and a program label with nearly the same name. I had a movf instruction that was supposed to load the register, but by accident, I'd used the program label as the operand. So, shifting the program up or down would change the value loaded by the movf instruction. All fixed now.

Good find, those are the hardest bugs to find. I know, I've had plenty.

Mike.

If I hadn't been so focused on memory page boundary issues, I would have found the error a lot sooner. It was right there in the subroutine that wasn't working. Anyway, that's one to remember.

This week I too have been re reading the information about PCLATH and crossing both 256 byte boundaries and 2K boundaries. In the past I have mainly used PCLATH for text stored as RETW instructions and I have only been concerned with 256 byte boundaries as the CALL instruction to the table of characters was always on the same page. This week I was writing code for a PIC12F1840 to read and do the calculations on a BPM280 (Pressure and temperature sensor.) I wanted to try to keep all of the code on the first memory page so I decided to move the text tables to the second page. This gave me the problem. I had not realised that PCLATH had to be set back to point to the page (2K page.) after returning from the call before the next CALL or GOTO instruction.

Les.

It brings back memories of programming the PDP-8.