Hi all,

I have written a program for the PIC16f84 in assembly. It basicly increases a number by one everytime an input pin is pull low and display this number.
It also scales this number to increase by 0.2 or 0.5 each count (depending on mode set by user)and displays this also.

Before it displays this, the user is prompted with a title screen and can select the scaling mode, either 0.2 or 0.5.

My problem is that my program halts roughly after the title screen if I add more instructions...it does not seem to matter what they are or where they are, it even happens when using 'NOP'. Without more instuctions my code works perfectly but I need to add more to finish other ideas I had for this program. Depending on how many more instructions I add determines how far the program will run untill it resets in hardware or crashes when simulating on PC.

My list file tells me that I have approx 70% of program memory left...
I am not using interrupts, it is all event driven.
I have made sure I return from all my subroutines and that there is never 8 nested ones. Made sure that I am in the correct bank as best as I could although MPLAB whines about this on 4 lines of my code, I expect this is because I'm addressing a register over 0x7F.
I have been through my code many many times and cannot find the problem.

Has anyone come across this issue before? Any ideas on what could cause this?

I can post my code if anyone is interested and willing to help me.

Thanks

Link to my code because it was too long to add here.

http://www.savefile.com/files/1762174

This code works but if i remove the comments from the instuctions commented-out under the 'MM_SCALE' subroutine (happens if added anywhere) it stops working and I get the problem described above.

 

Your problem is almost certainly the use of tables, without considering the crossing of 256 byte boundaries - move the tables to near the start of the programme, and jump over them.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

I cant thank you enough, Nigel! I really appreciate your help.

With the data tables up top, the programme now works as I intended it to.

Can you explain why this happens and where the crossing of 256 byte boundaries occur? I would like to know to save me headaches in future projects.

Cheers

 

Check the datasheet - the PCL register is only 8 bits wide, you need to manipulate the extra bits for it manually if you want to use other than the first page, or cross 256 byte boundaries. It keeps it simple by placing tables in the first page (and most of my tutorials do so for that reason).

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

Lucky you. I had an almost identical problem with a menu system for my LCD, but never resolved it. I think it was a 256 min-page issues, because I was frequently using a macro that expanded a string into a table. A look at the LST file didn't seem to corroborate this hypothesis, however.

piclist has a detailed page about the PCL and PCLATH. It seemed fairly comprehensive. There's also a brief Microchip App Note (AN556)

 

There is also a family (18F) where this problem is not a problem anymore.

__________________
Agustín Tomás
In theory, there is no difference between theory and practice. In practice, however, there is.

 

Yes, this is how I 'solved' my problem.

 

You can also calculate the address and therefore have tables anywhere.

To change the above code, you would do
You can also make your position variable 2 bytes and therefore have tables of any length.

BTW, instead of having lots of retlw instructions you can do,
which will produce the same code.

Mike.

 

Thanks for all the suggestions.

I might change my code to how your's looks Pommie, especially because I plan on using more tables.

Also, should I be sending all my update to the lcd data as strings? or just simply setting the cursor address and writing only the required values as I am currently doing?

I suppose each way has its benefits and downsides, but which is a better technique to adopt?

 

hi,
If you look at your original code listing it just crosses a Page boundary 7FF/800 when you add the extra code.

EDIT: disregard the Page boundary statement... its incorrect.

__________________
Eric
"Good enough is Perfect"

PIC tutorials:
Gramo's: www.digital-diy.net/
Bill's: www.blueroomelectronics.com/

 

There is no point in moving it into a string as to do that you would need a buffer in RAM which you have very little of. Best to just read it one character at a time and send it to the LCD.

@Eric,
I think you must have looked at different code to that above. When assembled it's only 0x174 long. Had it crossed a 0x800 boundary then that would have been a very different problem - not that it can happen on a 16F84.

Mike.

 

hi,
Thanks Mike, I'm sure I downloaded his 'Tester' program.. ahh well

Hows my horse doing.?


EDIT: back tracking, I see I downloaded that other file on that download page, not th 16F84.!

__________________
Eric
"Good enough is Perfect"

PIC tutorials:
Gramo's: www.digital-diy.net/
Bill's: www.blueroomelectronics.com/

 

Your horse is doing very well. He's happy at the moment because he has two other horses to keep him company and spring has just sprung.

Mike.

 

Hi Mike,
Thanks for the update.
Hope your summer is going to be better than hours was.!
We average about 200 hours of sunshine/summer, this year it was 96.

Figured out what I did wrong on that program, I like to analyse my mistakes so as not to repeat them. I used a hex viewer program rather than MPLAB of course I picked up the ASCII/Intel file.... a careless mistake, not to be repeated, I hope.

__________________
Eric
"Good enough is Perfect"

PIC tutorials:
Gramo's: www.digital-diy.net/
Bill's: www.blueroomelectronics.com/

 

I didn't know that, thanks for the information, I just knew it's been a miserable summer

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk