I'm editing a program on this old pic, after adding some code nothing works. I have done a lot of tests eliminating some code (randomly) and verified that if it is exceeded the 4K program it does not punctually work. Compiler ver. 0.09.02 always compiles regularly without errors.
Help
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes the source is the same, the thing that changes is only the added code that transmits data on the serial, nothing else. I have done a lot of tests in the last few days and the only thing I noticed is that adding even just a few instructions beyond 4K everything got stuck.
We catch up tomorrow afternoon
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To do tests + quickly (without the hardware card) I used RealPicSim, if you try you see the serial output sending out data, otherwise nothing comes out, try.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The seems to be incorrect setting of the PCLATH to the address 0x1000. PCLATH .3 and PCLATH .4 bits are being cleared which will set the PC to 0x0000 for the call.
Recommend using MPASM as the Assembler whilst I get Hugh to look at this mega issue. Actually, this is your only option to continue with project. I may figure it out but I feel that I need Hugh.
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Choose c:\microchip\mpasmx as the installation directory. If you choose another directory then you will have to change the setting in Programmer Preferences.
Once install, open Programmer Preferences, select Compiler tab and select MPASM as the Assembler.
Select OK.
All should be ok now.
I have emailed Hugh for him to resolve. I have not changed GCASM with respect to the PAGESEL code and it is too hard for me to resolve.
Why does GCASM issue "BCF PCLATH,4" rather than "BSF PCLATH,4" for these addresses ?
Why does MPASM work? This does prove the ASM is valid and therefore the fault is within GCASM.
Too hard to resolve.
Last edit: Anobium 2022-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An insight - this type of issue took two people over 12 man hours to resolve. And, then another 30 minutes to ship the fix.
This type of issue took many hours to stabilise a source program that enable the investigate to start - this includes ruling out simple errors. Then, it took 4 hours to walk the code in an emulator using the ASM to 'see' the error happen. Then, once the error was identified, try to understand cause. Isolation of issue within GCASM was proven by using MPASM. Then, comparing HEX files produced by GCASM and MPASM. Then, noting the error in the emulator was in the setting of PCLATH, examine the source code for GCASM. Then, understand the internals of GCASM, discussing with Hugh, change the source and test.
I am sharing because we need help - we need people with patience and the very best analysis skills. Ping me if you can help.
:-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Download the latest Patch ZIP it has the fix, copy to your installation and you can use GCASM again - there is NO need to use MPASM.
The issue was specific to 16f chips with PCLATH addressing bit when the address was greater than 4096 - the compiler was incorrectly handling the PCLATH bits. The issue was caused when you program required the compiler to place program code above the 4096 address. The addressing for tables etc is done differently so your program worked when the strings and tables were above 4096 but as you logic ( subs and functions grew) they were placed at or above 4096 = issue.
Anyway - all resolved. This was the most serious issue I have seen in years. It is good to find such a horrid issue as it stabilises the compiler in the new release. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm editing a program on this old pic, after adding some code nothing works. I have done a lot of tests eliminating some code (randomly) and verified that if it is exceeded the 4K program it does not punctually work. Compiler ver. 0.09.02 always compiles regularly without errors.
Help
Post your program as an attachment.
OK, you can see the operation even without hardware as it transmits serial data every 6 seconds.
What is the error message? messages? Please post.
Nessun messaggio di errore dal compilatore, il programma non lavora. Puoi anche usare simulatore per verificare TX seriale.
No error message from the compiler, the program does not work. You can also use simulator to verify serial TX.
This works instead, commented part of the code.
can you do this for me?
Compile using old version. Save the ASM.
Compiler using the version with the issue. Save the ASM.
Attach both ASMs to a post here.
Of course, no work
Work
So far the attachments are confusing me.
The ASM files are not the same source. One has a routine call 'STX1PINSETUP' then other does. Are they from the same source GCB?
The GCB source will help me analyse but I will be using the latest build to analyse.
Check back tomorrow morning.
Yes the source is the same, the thing that changes is only the added code that transmits data on the serial, nothing else. I have done a lot of tests in the last few days and the only thing I noticed is that adding even just a few instructions beyond 4K everything got stuck.
We catch up tomorrow afternoon
What is a valid test in an emulator? I dont have DS18B20 etc etc. I compile and what is meant to happen?
To do tests + quickly (without the hardware card) I used RealPicSim, if you try you see the serial output sending out data, otherwise nothing comes out, try.
The seems to be incorrect setting of the PCLATH to the address 0x1000. PCLATH .3 and PCLATH .4 bits are being cleared which will set the PC to 0x0000 for the call.
This looks correct in the ASM
However, in the HEX the Op Codes are not correct.
Recommend using MPASM as the Assembler whilst I get Hugh to look at this mega issue. Actually, this is your only option to continue with project. I may figure it out but I feel that I need Hugh.
Evan
I can CONFIRM the issue is within GCASM. Please use MPASM - it is just as fast and it it is easy to install.
All should be ok now.
I have emailed Hugh for him to resolve. I have not changed GCASM with respect to the PAGESEL code and it is too hard for me to resolve.
Why does GCASM issue "BCF PCLATH,4" rather than "BSF PCLATH,4" for these addresses ?
Why does MPASM work? This does prove the ASM is valid and therefore the fault is within GCASM.
Too hard to resolve.
Last edit: Anobium 2022-09-06
I have resolved and Hugh has confirmed the generic approach is valid.
The resolution will be published in build 1165. You need to get onto this build to resolve.
I have resolved and Hugh has confirmed the generic approach is valid.
The resolution will be published in build 1165. You need to get onto this build to resolve.
An insight - this type of issue took two people over 12 man hours to resolve. And, then another 30 minutes to ship the fix.
This type of issue took many hours to stabilise a source program that enable the investigate to start - this includes ruling out simple errors. Then, it took 4 hours to walk the code in an emulator using the ASM to 'see' the error happen. Then, once the error was identified, try to understand cause. Isolation of issue within GCASM was proven by using MPASM. Then, comparing HEX files produced by GCASM and MPASM. Then, noting the error in the emulator was in the setting of PCLATH, examine the source code for GCASM. Then, understand the internals of GCASM, discussing with Hugh, change the source and test.
I am sharing because we need help - we need people with patience and the very best analysis skills. Ping me if you can help.
:-)
Well, tonight I had a lot of commitments and I'm tired, tomorrow morning I will rehearse following your advice.
Thank you
Yes all OK, I used the old MPASMWIN and I confirm that everything works fine, but this problem involved all 16F pic or just some.
Great news.
Download the latest Patch ZIP it has the fix, copy to your installation and you can use GCASM again - there is NO need to use MPASM.
The issue was specific to 16f chips with PCLATH addressing bit when the address was greater than 4096 - the compiler was incorrectly handling the PCLATH bits. The issue was caused when you program required the compiler to place program code above the 4096 address. The addressing for tables etc is done differently so your program worked when the strings and tables were above 4096 but as you logic ( subs and functions grew) they were placed at or above 4096 = issue.
Anyway - all resolved. This was the most serious issue I have seen in years. It is good to find such a horrid issue as it stabilises the compiler in the new release. :-)
Well, once the fear is over, it only takes a bit to go crazy.
Thanks for the quick resolution.
Gigi
Pleasure!