THIS IS NOT A DAT FILE ERROR - THIS WAS A COMPILER ISSUE. A COMPILER LATER THEN 30th Sept 2020 resolves
I have changed the old file with the new with correct ram size.
It give me this error:
Aborting due to runtime error 6 (out of bounds array access) at line 14361 of D:\code\GCBASIC\trunk\gcbasic.bas::READCHIPDATA()
Last edit: Anobium 2020-09-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The version is 0.98.06 2019-06-12
The source file is big with some include files.
If you give me an email address I will send you a zip with all files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The program was compiled without errors.
However, I found some errors in the string handling.
I'll explain:
In my program I display data on an LCD display with also graphic symbols.
With the new compiler these characters were not displayed to me. I started a step-by-step verification by partializing various areas of the program and finally I discovered that the problem was due to the size of a string:
Dim sString as string * 6
It looked OK ...
After many tests I spaced the 6 from the symbol * and the program, at least in that part, worked.
I have encountered another problem in the transfer of strings that is not happening correctly.
I have prepared a test program where the error occurs and a screenshot with the result obtained.
In practice it is a question of making a string exit from the serial port that I pass to an output routine.
Code:
' $formattagcb
#OptionExplicit' -' -
#Chip16F18857, 32
#ConfigOSC=INT, MCLR_OFF' -' Configurazione dei pins per la seriale e il bus I2C
#startupInitPPS, 85
#DefinePPSTOOLPART16f18857' - Setup Serial port
#DefineUSART_BAUD_RATE2400' #Define USART_TX_BLOCKING' #Define USART_DELAY 5 ms' #Define USART_BLOCKING' -
#DefineSERINPORTPORTB.2
#DefineSEROUTPORTPORTB.5DimCntAsByte' -Cnt=0DoForEverPrintst("Count=", 0)Wait100msPrintst(STR(Cnt), 1)Wait100msCnt++Loop' -' -' ========================================================================' Scrive una stringa sulla seriale' ------------------------------------------------------------------------SubPrintst(inStringaAsString, OptionalNumCrlfAsByte=0)HSerPrintStringaIfNumCrLfThenRepeatNumCrLfHSerPrintCrLfEndRepeatEndIfEndSub' -' -SubInitPPS' Generated by PIC PPS Tool for Great Cow Basic' PPS Tool version: 0.0.5.26' PinManager data: v1.76' Generated for 16f18857' -UnLockPPS' Module EUSARTRB5PPS=0x0010'TX > RB5RXPPS=0x000A'RB2 > RX' Module MSSP1SSP1DATPPS=0x0009'RB1 > SDA1RB1PPS=0x0015'SDA1 > RB1 (bi-directional)RB4PPS=0x0014'SCL1 > RB4SSP1CLKPPS=0x000C'RB4 > SCL1 (bi-directional)LockPPSEndSub
On this program that I'm writing I used the compiler 0.98.07.
The same source code compiled with version 0.98.06 produced me a code of 20227 bytes and 2018 bytes of RAM.
With the .07 version the code is 20102 bytes and the RAM used is 2017, therefore a good saving of program memory.
However, I found a problem that I was unable to solve,
now I'll explain:
In my program (over 6000 lines of code) in the display I use graphic characters created with "LCDCreateChar". With the previous compiler you can see perfectly, with version .07 I see characters completely different from those generated and, always the same character for each of the graphic characters created, that is, for each different graphic character the same "strange" character is always displayed .
If I use the "LCDCreateChar" instruction on a new test program, everything works fine.
As I said the code is over 6000 program lines and to work and see the results on the display it must be connected to other hardware.
The .06 version does not give any problems ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you. I have examined the [FreeRAM] section. I see no errors. There is a long list of RAM location (very different from V06 ) but they add up to 4096 - which is correct.
Try using the V06 with the new compiler. I want to know if I even looking in the correction place. Rename to V07 (you will need it!).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And, looking at the old V06... this would not have worked as exepted. The chipRAM = 4096 but the actual RAM map is for a 2048 RAM device. I am not sure woud have happened when the RAM address went about 2048!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. I'm away from home right now.
It seems strange to me that the .06 compiler with its .dat file allows me to run the whole program without any problem.
As soon as I return, I send you the source files.
Send me an email address where I can send you the files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The root cause is the cause that BANK 32 of the RAM is being incorrectly handled. It is impact the following chips.
PIC16F18857
PIC16F18877
PIC16F19197
I have created a test program that uses every byte of RAM, and, whilst the compiler handles the assignment of the RAM correctly the generated ASM is incorrect.
There is also a related issue where the memory map description for these chips prior to v0.98.07 is incorrect.
We are working the solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One for devices with 32 banks:
"00 0000 001k kkkk" The 9-bit prefix 00 0000 001 was unassigned in the Baseline Mid-range devices.
And one for Enhanced Mid-range devices with 64 banks:
"00 0001 01kk kkkk" Which uses some of the unused encodings previously occupied by CLRW;
CLRW must now be encoded as: "00 0001 0000 00xx"
See the PIC16F18857 datasheet, which correctly shows "00 0001 01kk kkkk" (14 bits).
this is little known; I hope this helps you fix this problem...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
THIS IS NOT A DAT FILE ERROR - THIS WAS A COMPILER ISSUE. A COMPILER LATER THEN 30th Sept 2020 resolves
I have changed the old file with the new with correct ram size.
It give me this error:
Aborting due to runtime error 6 (out of bounds array access) at line 14361 of D:\code\GCBASIC\trunk\gcbasic.bas::READCHIPDATA()
Last edit: Anobium 2020-09-30
How odd.
What version of the compiler?
Can you attach the dat file and your source program. Please.
Anobium
The version is 0.98.06 2019-06-12
The source file is big with some include files.
If you give me an email address I will send you a zip with all files.
Try the current Release Candidate first. See the files tab. install to a new directory. Test and report back.
OK
The new compiler is Ok. No errors.
Now I try it in practice and see if the compiled works well.
Thanks Anobium
OK. The RC code is stable and you cam use safely.
The program was compiled without errors.
However, I found some errors in the string handling.
I'll explain:
In my program I display data on an LCD display with also graphic symbols.
With the new compiler these characters were not displayed to me. I started a step-by-step verification by partializing various areas of the program and finally I discovered that the problem was due to the size of a string:
Dim sString as string * 6
It looked OK ...
After many tests I spaced the 6 from the symbol * and the program, at least in that part, worked.
I have encountered another problem in the transfer of strings that is not happening correctly.
I have prepared a test program where the error occurs and a screenshot with the result obtained.
In practice it is a question of making a string exit from the serial port that I pass to an output routine.
Code:
This is because the USART routines have been optimised.
I have reproduced your issue and if you add the USART_TX_BLOCKING this should resolve your issue.
~~~
#Define USART_BAUD_RATE 2400
#Define USART_TX_BLOCKING
#Define USART_DELAY 0
~~~
and, you cannot use Software serial and Hardware serial unless you are turning PPS on and off as you use Software serial.
Anobium
Last edit: Anobium 2020-09-15
On this program that I'm writing I used the compiler 0.98.07.
The same source code compiled with version 0.98.06 produced me a code of 20227 bytes and 2018 bytes of RAM.
With the .07 version the code is 20102 bytes and the RAM used is 2017, therefore a good saving of program memory.
However, I found a problem that I was unable to solve,
now I'll explain:
In my program (over 6000 lines of code) in the display I use graphic characters created with "LCDCreateChar". With the previous compiler you can see perfectly, with version .07 I see characters completely different from those generated and, always the same character for each of the graphic characters created, that is, for each different graphic character the same "strange" character is always displayed .
If I use the "LCDCreateChar" instruction on a new test program, everything works fine.
As I said the code is over 6000 program lines and to work and see the results on the display it must be connected to other hardware.
The .06 version does not give any problems ...
Please upload ASM files from both compilers.
As we have not changed the LCD CreateChar we need to look elsewhere.
OK.
Source included.
This may be a memory defintion issue. Please upload both chip .dat file from both versions.
OK.
Chip.dat included
Thank you. I have examined the [FreeRAM] section. I see no errors. There is a long list of RAM location (very different from V06 ) but they add up to 4096 - which is correct.
Try using the V06 with the new compiler. I want to know if I even looking in the correction place. Rename to V07 (you will need it!).
And, looking at the old V06... this would not have worked as exepted. The chipRAM = 4096 but the actual RAM map is for a 2048 RAM device. I am not sure woud have happened when the RAM address went about 2048!
And, wading thru your asm...
Looks ok here in the simulator... are these your chars?
Do you have
#option explicit
set?Last edit: Anobium 2020-09-21
This does look seriius. The ASM had 38 inccorect or missing BANKSELs,
Problably the DAT file but I do not know. I need the source GCB program.
OK. I'm away from home right now.
It seems strange to me that the .06 compiler with its .dat file allows me to run the whole program without any problem.
As soon as I return, I send you the source files.
Send me an email address where I can send you the files.
OK. It is not strange howerver.
06 - may have worked but the memory map was incorrect.
07 - the memory map is correct but it has BANKSEL errors. Lots of them.
So, we can revert all the 4096RAM chips (all of them) back to 2048RAM,or, we resolve properly.
07 is currently a release candidate with 100s of fixes. And, there will be issues along the way. Sorry.
Send me a Personal Message for my email address.
I have investigated, a lot, more.
The root cause is the cause that BANK 32 of the RAM is being incorrectly handled. It is impact the following chips.
PIC16F18857
PIC16F18877
PIC16F19197
I have created a test program that uses every byte of RAM, and, whilst the compiler handles the assignment of the RAM correctly the generated ASM is incorrect.
There is also a related issue where the memory map description for these chips prior to v0.98.07 is incorrect.
We are working the solution.
Dear Evan,
There now exist two different encodings forthe MOVLB instruction on Enhanced Mid-range devices; see https://www.microchip.com/forums/m1131489.aspx
One for devices with 32 banks:
"00 0000 001k kkkk" The 9-bit prefix 00 0000 001 was unassigned in the Baseline Mid-range devices.
And one for Enhanced Mid-range devices with 64 banks:
"00 0001 01kk kkkk" Which uses some of the unused encodings previously occupied by CLRW;
CLRW must now be encoded as: "00 0001 0000 00xx"
See the PIC16F18857 datasheet, which correctly shows "00 0001 01kk kkkk" (14 bits).
this is little known; I hope this helps you fix this problem...
We resolved this a while ago. But, thank you.
@JackJames. My email are not getting to you.
Please email me your project. I cannot test with no project but here is video of my analysis todate.
Last edit: Anobium 2020-09-30