The csv file actually looks ok. The entry for NoBankRam is correct at 70:7F. However the csv does not have an entry for FreeRam so that must come from elsewhere.
Is possible that these two files are being missed in the generation process?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I corrected the 12F(HV)752 datfiles at Github for now. However, I know they will get overwritten next time the generator runs. I tested these on silicon and the chip runs ok now.
Let me know if you need anything more.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The update will require the source BAS to be resolved when the next build process runs.
The issue with the 12f will be the getchipdata exe, therefore, the within the BAS source. I am thinking that this may be as simple as an uninitialized variable. Hugh dI'd not initialize variables (he was very young) and therefore, sometimes, a DAT picks up the value from the previous chip!
Essentially, this is a simple fix that just needs some thought/code inspection to fix the BAS source.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have updated the GetChipData source to correctly handle chips with 64bytes of RAM. There we errors across a series of chips like the 12F(HV)752 where the GetChipData tool was not correctly reading the source CSV correctly.
The GetChipData process now gens chips with 64 bytes of RAM correctly.
Committed to GitHub no change to any DAT as a result of this change.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Problem: Code does not execute after programming
Device: PIC12F/HV752 ( Possibly others)
Compiler: 0.99.02 2022-05-12 (Windows 64 bit) : Build 1121
The FreeRAM and NoBankRam entries are incorrect in the .dat file causing variables to be mapped to invalid RAM locations.
Current Datafile:
[FreeRam]
20:5F
[NoBankRAM]
20:5F
Should be ??? :
[FreeRam]
40:7F
[NoBankRAM]
70:7F
Last edit: William Roth 2022-06-08
I recommend that this is updated in GitHub.
Mainly because I am travelling and this post can't be flagged for an action by someone.
https://github.com/GreatCowBASIC/DATFileGenerator/blob/main/chipdata.csv
Last edit: Anobium 2022-06-08
The csv file actually looks ok. The entry for NoBankRam is correct at 70:7F. However the csv does not have an entry for FreeRam so that must come from elsewhere.
Is possible that these two files are being missed in the generation process?
There root cause is in the exe. These files are being generated as part of the build process therefore the error is in the GetChipData exe.
My guess is that there no appropriate handler for these chips (looks to me that about 8 chips are impacted). The source bas file needs to updated.
Last edit: Anobium 2022-06-09
OK.
I corrected the 12F(HV)752 datfiles at Github for now. However, I know they will get overwritten next time the generator runs. I tested these on silicon and the chip runs ok now.
Let me know if you need anything more.
Thank you.
The update will require the source BAS to be resolved when the next build process runs.
The issue with the 12f will be the getchipdata exe, therefore, the within the BAS source. I am thinking that this may be as simple as an uninitialized variable. Hugh dI'd not initialize variables (he was very young) and therefore, sometimes, a DAT picks up the value from the previous chip!
Essentially, this is a simple fix that just needs some thought/code inspection to fix the BAS source.
I have updated the GetChipData source to correctly handle chips with 64bytes of RAM. There we errors across a series of chips like the 12F(HV)752 where the GetChipData tool was not correctly reading the source CSV correctly.
The GetChipData process now gens chips with 64 bytes of RAM correctly.
Committed to GitHub no change to any DAT as a result of this change.