Pic program stops working if more instuctions are added

[spitfire]

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.

https://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.

 

[Nigel Goodwin]

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.

 

[spitfire]

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

 

[Nigel Goodwin]

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.

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).

 

[astronomerroyal]

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)

 

[atferrari]

There is also...

There's also a brief Microchip App Note (AN556)

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

 

[astronomerroyal]

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

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

 

[Pommie]

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

To change the above code, you would do

MENU_L0
	addlw	low(Table)	;calculate low byte
	movwf	temp		;save for later
	movlw	high(Table)	;get high byte
	btfsc	STATUS,C	;was there a carry from low calculation
	addlw	1		;yes, inc W
	movwf	PCLATH		;store in holding reg for high byte of PC
	movfw	temp		;retrieve low byte
	movwf	PCL		;do jump

Table	RETLW	0x04D	; ASCII 'M'
	RETLW	0X06F	; ASCII 'o'
	RETLW	0X064	; ASCII 'd'
	RETLW	0X065	; ASCII 'e'
	RETLW	0X002	; space
	RETLW	0X053	; ASCII 'S'
	RETLW	0X065	; ASCII 'e'
	RETLW	0X06C	; ASCII 'l'
	RETLW	0X065	; ASCII 'e'
	RETLW	0X063	; ASCII 'c'
	RETLW	0X074	; ASCII 't'
	RETLW	0x002	
	RETLW	0x002
	RETLW	0X002
	RETLW	0X000	; End of string

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,

	dt	"Mode Select",2,2,2,0

which will produce the same code.

Mike.

 

[spitfire]

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?

 

[ericgibbs]

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.

 

[Pommie]

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?

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.

 

[ericgibbs]

@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.!

 

[Pommie]

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.

 

[ericgibbs]

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.

 

[Nigel Goodwin]

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.

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

 

[ericgibbs]

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

A more detailed summary link, just to cheer you up..

**broken link removed**

 

[Nigel Goodwin]

A more detailed summary link, just to cheer you up..

**broken link removed**

Thanks, I feel much better now!