• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Magic nop's and a baffling program bug

BobW

Active Member
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?
 

Pommie

Well-Known Member
Most Helpful Member
means that PCLATH should never have to be loaded with anything other than zero.
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.
 

BobW

Active Member
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.
 

Pommie

Well-Known Member
Most Helpful Member
Good find, those are the hardest bugs to find. I know, I've had plenty. :oops:

Mike.
 

BobW

Active Member
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.
 

Les Jones

Well-Known Member
Most Helpful Member
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.
 

EE World Online Articles

Loading

 
Top