| View previous topic :: View next topic |
| Author |
Message |
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| I need some more expansion on this! And some Help Please. |
 Posted: Fri Dec 05, 2003 3:50 pm |
 |
|
Hello
I'm back to working on this ROM checking thing again.
First in the data sheet for the 18F452 it shows that the flash memory stops at 0x20000 and program memory stops at 0x7FFF.
So what is the checksum 'ID' doing at 0x20000 ? 0x20007?
Is this flash memory that Microchip is not telling us about in the data sheet?
And I have the same question for the configuration words at 0x300000 ?0x30000C?
Notwithstanding I put Darren's code in to my program and the numbers don?t match when the program runs.
Is there more math that I need to do with the output number?
Darren was just showing us how to get the numbers?
The CCS compiler book show that read_program_eeprom returns a 16 bit number why are we using the make16 function? (see below)
make16(read_program_eeprom(0x200001),read_program_eeprom(0x200000));
I though that the program memory in the 18Fxxx parts is 16 bits wide?
An help would be greatly appreciated!
Thank All, Tom |
|
 |
Darren Rook
Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI
|
| Re: I need some more expansion on this! And some Help Please |
| Posted: Fri Dec 05, 2003 5:02 pm |
|
|
| Tom-H-PIC wrote: | Hello
I’m back to working on this ROM checking thing again.
First in the data sheet for the 18F452 it shows that the flash memory stops at 0x20000 and program memory stops at 0x7FFF.
So what is the checksum “ID” doing at 0x20000 – 0x20007?
|
To quote Microchip:
| Code: | [b]19.5 ID Locations[/b]
Eight memory locations (200000h - 200007h) are des-ignated
as ID locations, where the user can store
checksum or other code identification numbers. These
locations are accessible during normal execution
through the TBLRD and TBLWT instructions, or during
program/verify. The ID locations can be read when the
device is code protected. |
and
| Code: | [b]19.1 Configuration Bits[/b]
The configuration bits can be programmed (read as '0'),
or left unprogrammed (read as '1'), to select various
device configurations. These bits are mapped starting
at program memory location 300000h.
The user will note that address 300000h is beyond the
user program memory space. In fact, it belongs to the
configuration memory space (300000h - 3FFFFFh),
which can only be accessed using Table Reads and
Table Writes. |
| Quote: |
Notwithstanding I put Darren’s code in to my program and the numbers don’t match when the program runs.
Is there more math that I need to do with the output number?
Darren was just showing us how to get the numbers?
|
No math is needed. One line that is displayed represents the ID programed into 0x20000-0x20007. The second line that is displayed is what is calculated. If the test works then both lines should be the same.
I will try it again next week to see why it doesn't work.
| Quote: | The CCS compiler book show that read_program_eeprom returns a 16 bit number why are we using the make16 function? (see below)
make16(read_program_eeprom(0x200001),read_program_eeprom(0x200000));
I though that the program memory in the 18Fxxx parts is 16 bits wide? |
When I wrote that test program, I didn't know that read_eeprom() returned 16bit values. I thought it returned 8bit numbers. The documentation isn't very good, IMO, about this. |
|
|
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| I'm so confused by #ID |
| Posted: Mon Dec 08, 2003 9:50 am |
|
|
Darren thanks for the info on the 0x200000 and 0x300000 address.
I was looking at the readme file and found that CCS changed the read_program_eeprom from reading 8 bits to read 16 bits for PIC18 parts. I think that this was about compiler 3.151 so if you are using a compiler below this it is only 8 bit return value.
Notwithstanding I have worked on this on and off all weekend. The conclusion that I have come to is that CCS has implemented this in a way that it does not work correctly.
The reason that I say that is. Looking at the hex files last lines I can see the checksum that the programmer is going to write to 'ID' address locations. If a person compiles there program and looks at the number it will be one value then if we recompile the program with out changing a thing the value of the checksum number in the hex file will change.
I would think that if nothing is changed in the source code file that the hex file checksum would be the same every time.
I have also noticed that the location of #ID CHECKSUM in the program makes a big difference.
If a person puts #ID checksum after all of the compiler pre-processors commands the checksum in the hex file will be one value and then if #ID checksum is moved to just before main the checksum value will change.
In thinking about this now this may be right I don't know.
My program has to check some type of checksum on startup.
So I may have to write my own checksum thing.
I was thinking of storing the checksum value in EEPROM (already have the sub in the program for read and write 16 bit data to EEPROM).
That way on the first run if the read value is 0xFFFF then I would store the checksum value then on the next boot I would read and compare the values.
I would use a simple checksum of just a 16 bit value of all the program memory location added up.
What do you think of that for a work around?
Thanks All
Tom |
|
|
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| This is the work around that i used! |
| Posted: Wed Dec 10, 2003 11:14 am |
|
|
Ok reporting back to all that are interested.
This is the work around that I have come up with.
This is set up for a PIC18 if your going to use a PIC16 you will need to change the address for the main memory and ID and Configuration word locations.
This info is in the data sheet under memory and special features if the CPS. As pointed out by Darren Rook in a post before.
Thanks Darren.
I use the ICD-U40 from CCS for programming.
For this to function to work right the programmer has to be set for ?Bulk erase on write ? under the advanced settings.
With this setting the ID locations will get set to 0xFFFF on each new programming.
What this function will do is check if the first ID location is 0xFFFF. If it is 0xFFFF this indicates to the function that this is the first time that the program has ever run.
The function will write the simple checksum number in to the ID location.
The next time the program runs the function will compare the calculated checksum number to the number stored at ID location.
If the numbers are equal the flash memory has not been corrupted and the function returns true.
I know that a much more complicated checksum function would be better in some respects but this will work for this project.
Thank You to all that helped on this.
Tom
| Code: | // Calculation ROM memory
int1 rom_check(){
int32 Rom_address;
unsigned long romcheck = 0x0000, cs_temp;
// Calculate checksum of all program flash.
for (Rom_address = 0; Rom_address < getenv("PROGRAM_MEMORY"); Rom_address+=2){
cs_temp = read_program_eeprom(Rom_address);
romcheck += cs_temp;}
// Include all configuration words (as 16 bit numbers) into checksum.
for (Rom_address = 0x300000; Rom_address <= 0x30000D; Rom_address+=2){
cs_temp = read_program_eeprom(Rom_address);
romcheck += cs_temp;}
// Check if this is rhe first run of the code by checking for a checksum
if (read_program_eeprom(0x200000) == 0xFFFF){
write_program_eeprom(0x200000,romcheck);}
if (read_program_eeprom(0x200000) == romcheck){
return True;} // -- CheckSum is OK --
return(False);} // CheckSum error |
|
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Wed Dec 10, 2003 11:42 am |
|
|
The following line will place the checksum in the ID locations for you.
There shouldn't be a need to do it on a first time run. |
|
|
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| Yes #ID checksum puts a number in that location BUT! |
| Posted: Wed Dec 10, 2003 1:37 pm |
|
|
Mark I agree that #ID CHECKSUM will put a checksum numbers in the ID locations.
But if you review all of this thread you will see that the code that Darren was kind enough to supply did not work in my large program.
So I spent about 25 hours trying to figure out how CCS generates this checksum and a way to check it at run time with the PIC.
I have come to the conclusion that the checksum that CCS puts in the checksum location cannot be checked at run time by the PIC.
So the two biggest issues that I see are.
1. #ID CHECKSUM no one knows how CCS generates this number and what it is a CHECKSUM of.
2. The checksum number will change by just recompiling the program, NO changes to the code at all just recompiling.
I would real like to know how CCS generates the checksum number and it is not the way Microchip talks about in TB0026.
So if you know how CCS generates the checksum number and you have a program that can test that checksum at run time would you please share it.
I have the view that you did Mark in your post on NOV. 13 that #ID CHECKSUM is worthless.
Tom   |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Wed Dec 10, 2003 2:23 pm |
|
|
| I did get Darren's code to work when I used a newer compiler. The ID's matched. Are you saying that it only works with a small program and not a large one? |
|
|
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| NOT for me |
| Posted: Wed Dec 10, 2003 3:48 pm |
|
|
I was not able to get Darren's code to work for me. I tried for about 25 hours.
I'm using a PIC18F452 and I have used up about 85% of the flash memory.
I used compiler 3.180 and had no luck in making it work.
Tom |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
