Hi,
I'm starting to experience strange program corruptions if my code grow after 2Kbyte.....No erros from compiler, but crossing this code dimension with every new instruction, make program work randomly.
Any Idea?
I'm actually working on PIC 16F690 (With 4 Kbyte program memory).
Greetings
Stefano Bonomi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pic Program Memory is divided in so called Banks, in other words memory pages as follows:
Core Size Page Size
12-bit 512
14-bit 2048
16-bit 8192
For 16F690 (14 bit core) the PC is 13 bit Long.
GOTO and CALL instructions computes the branch address taking the lower 11 bits from the instruction, the higher bits comes from two bits (3 and 4) of PCLATH register.
If you don't modify these bits of PCLATH, PIC always jump around Page 0, meaning between 0 and 7FF for 14 bit PIC core.
Checking compiled file of my program (that cross page 0 of PIC 16F690), I've found no trace of PCLATH bit 3 and 4 modification nor PAGESEL instructions....
Manual adding the right instructions for Memory Page selection to assembler File prior to GPUTILS compilation, I was able to run my program (look at my previous Post) without any issue.....
This means, I assume, that actually we are limited to 2KB program lenght.
Greetings
Stefano Bonomi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've added some page selection code to GCBASIC. To enable page selection, add a line to the program that reads:
#option lcall
This will cause GCBASIC to use lcall and lgoto in place of call and goto. There is also some new code which is designed to prevent subroutines from crossing page boundaries by inserting ORG directives where needed.
My code Overlap Page 1 and GCBasic start at beginning of page 1 with the subroutines.
When I try to compile my program, GPutils reports a lot of "Overwriting previous address contents." errors
Looking at the produced assembler listing, my code goes till 09ED hexadecimal and then there is an "ORG 2048" put there from GCBasic.
Thanks anyway
Stefano Bonomi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Noticed similar instability in a longer program. Chased my tail way to long debugging, when an extra "if" or "and" statement would not work as expected or just froze the program, all the while compiling and assembled successfully. Finally remembered this thread, and checked the memory words were at 2068 or just over the page boundary.
Put in the "#option lcall" and all is well now; Thank you very much for that!.
Is it worth a warning here when a page boundary is passed? I disabled this define call and recompiled the offending program, and right back to freeze up, with no compilation or assembly error notice.
Kent
P.S. Using a 16f88
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good Idea Kent, people could save a lot of time of nonsense debugging with a compiler warning like the one you suggest.
Would like to request further optimisation on this problem; actually GCBasic add "lcall" and "pagesel $" for every call instruction, also when is not necessary i.e. call in the same memory page, thus "eating" lot of memory space.
Anyway "#option lcall" directive is working, and this is so far the most important point!
(Thanks again)
Greetings
Stefano Bonomi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm starting to experience strange program corruptions if my code grow after 2Kbyte.....No erros from compiler, but crossing this code dimension with every new instruction, make program work randomly.
Any Idea?
I'm actually working on PIC 16F690 (With 4 Kbyte program memory).
Greetings
Stefano Bonomi
Mmmmm......
Pic Program Memory is divided in so called Banks, in other words memory pages as follows:
Core Size Page Size
12-bit 512
14-bit 2048
16-bit 8192
For 16F690 (14 bit core) the PC is 13 bit Long.
GOTO and CALL instructions computes the branch address taking the lower 11 bits from the instruction, the higher bits comes from two bits (3 and 4) of PCLATH register.
If you don't modify these bits of PCLATH, PIC always jump around Page 0, meaning between 0 and 7FF for 14 bit PIC core.
Checking compiled file of my program (that cross page 0 of PIC 16F690), I've found no trace of PCLATH bit 3 and 4 modification nor PAGESEL instructions....
Manual adding the right instructions for Memory Page selection to assembler File prior to GPUTILS compilation, I was able to run my program (look at my previous Post) without any issue.....
This means, I assume, that actually we are limited to 2KB program lenght.
Greetings
Stefano Bonomi
I've added some page selection code to GCBASIC. To enable page selection, add a line to the program that reads:
#option lcall
This will cause GCBASIC to use lcall and lgoto in place of call and goto. There is also some new code which is designed to prevent subroutines from crossing page boundaries by inserting ORG directives where needed.
The update is in http://gcbasic.sourceforge.net/newfiles/update.zip
It doesn't work Hugh
My code Overlap Page 1 and GCBasic start at beginning of page 1 with the subroutines.
When I try to compile my program, GPutils reports a lot of "Overwriting previous address contents." errors
Looking at the produced assembler listing, my code goes till 09ED hexadecimal and then there is an "ORG 2048" put there from GCBasic.
Thanks anyway
Stefano Bonomi
Could you please post the program here or email it to me at w_cholmondeley@users.sourceforge.net ?
Done!
Sent by e-mail because of program lenght
I've made a few more changes, and your program now compiles and assembles fine. Hopefully it will run!
http://gcbasic.sourceforge.net/newfiles/update.zip
Still not working!
I have to manually insert
Pagesel $
in the compiled.asm file after all lcalls. If I don't do so, the program branch wrong at goto instructions after sub returning.
Lcall macro doesn't restore PCLath after returning.....
Greetings
Stefano Bonomi
I've done some more work, and GCBASIC should now add the pagesel after the lcalls. Please try http://gcbasic.sourceforge.net/newfiles/update.zip again.
Thanks for being so patient!
Hi Hugh, all OK after your latest modification.....
Thanks a lot
Stefano Bonomi
Noticed similar instability in a longer program. Chased my tail way to long debugging, when an extra "if" or "and" statement would not work as expected or just froze the program, all the while compiling and assembled successfully. Finally remembered this thread, and checked the memory words were at 2068 or just over the page boundary.
Put in the "#option lcall" and all is well now; Thank you very much for that!.
Is it worth a warning here when a page boundary is passed? I disabled this define call and recompiled the offending program, and right back to freeze up, with no compilation or assembly error notice.
Kent
P.S. Using a 16f88
Good Idea Kent, people could save a lot of time of nonsense debugging with a compiler warning like the one you suggest.
Would like to request further optimisation on this problem; actually GCBasic add "lcall" and "pagesel $" for every call instruction, also when is not necessary i.e. call in the same memory page, thus "eating" lot of memory space.
Anyway "#option lcall" directive is working, and this is so far the most important point!
(Thanks again)
Greetings
Stefano Bonomi