Apparent code size problem
I am having a problem that appears to be related to code size. The chip is 16F917, PBP version is 2.46
The total code size is over 4000 words Everything compiles and one version of the code works just fine. However a small change is one subroutine to make it more user friendly seems to break eveything. It appears to fail to initialize properly ( based on fact that the opening splash screen never displays and the instrument will not respond to any of the inputs it should immediately after power up). The code is for a company project and so I can not post it all, but I have posted the two code snippets, the total word count of the program when using each variation and the address range
I encountered this problem once or twice before during this project and both times a change in code size has corrected it. Once was nothing more than adding a line like X = X. This leads me to think it may be some type of boundry issue, but I have to admit I am new enough to PICs and PBP that I am more than a little confused at this time.
Any help or suggestions would be appreciated.
The one that works:
4145 words
0-1037 address range
IF (OhmCheck = FAILED) or _ ' resistor out of tolerance or
(FlagResult <> 0) then ' hardware flag
GOSUB Houston
ENDIF
-------------------------------------------------
Replace it with this one and it does not work:
4281 words
0-10bf address range
IF OhmCheck = FAILED THEN
ErrCnt = ErrCnt + 1
IF ErrCnt = 1 then 'first time gets a pass for a recheck
Device = DISPLAY
GOSUB SetCtrl
LCDOUT $FE,1,"Chk Dckbill conn"
LCDOUT $FE,$C0,"then retry test"
PAUSE 1000
ENDIF
ENDIF
IF (ErrCnt > 1) or (FlagResult <> 0) THEN
GOSUB Houston
ENDIF
I think I have seen this before
What you say looks like something I had some time ago. Check the forum for broken code. http://www.picbasic.co.uk/forum/showthread.php?t=5674
The problem is when you add a new variable PBP makes a word variable span 2 banks and that is not allowed. If this happens you get "The Harry Potter Syndrome" black magic and nothing is logical anymore. I fixed this for my 18F4620 pic by adding a dummy variable at the last address in each bank. For example:
bogus_0 VAR BYTE $7F ' force a byte at location 07F
bogus_1 VAR BYTE $0FF ' force a byte at location 0FF
bogus_2 VAR BYTE $1FF ' force a byte at location 1FF
bogus_3 VAR BYTE $2FF ' force a byte at location 2FF
bogus_4 VAR BYTE $3FF ' force a byte at location 3FF
bogus_5 VAR BYTE $4FF ' force a byte at location 4FF
bogus_6 VAR BYTE $5FF ' force a byte at location 5FF
bogus_7 VAR BYTE $6FF ' force a byte at location 6FF
bogus_8 VAR BYTE $7FF ' force a byte at location 7FF
Make sure you get the location right, depending on MCU you should go for different values. Look in the .ASM file for your compiled program and early you will find:
BANK0_START EQU 00080h
BANK0_END EQU 000FFh
BANK1_START EQU 00100h
BANK1_END EQU 001FFh
BANK2_START EQU 00200h
BANK2_END EQU 002FFh
BANK3_START EQU 00300h
BANK3_END EQU 003FFh
Use the END value for you bogus variable and PBP can not make this misstake. Make sure you include BANKA also in the fix.
Hope this will help to remove Harry Potter from your code. And YES MELABS knows about this because they helped me to find it.
Mike
Try the dummy variable fix
This is what I had, I changed in one place and it died in another. If you check the asm file that you have on the NOT working program it is easy to see. Just look at the end address for each bank and most likely you will see Byte0 of a Word variable there. Byte1 will be in then next bank and this messes up all the RAM area for you even if you don't use that variable in the start of your program.
M