| View previous topic :: View next topic |
| Author |
Message |
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| ROM image check on start up |
 Posted: Tue Nov 11, 2003 7:28 am |
 |
|
Hello All
I know that I have seen this topic on this forum someplace.
But the search is not being to big of help, so if some one knows what to search for or has the code please let me know.
I need to have the PIC18F452 that I’m work with read and verify that it flash ROM has not been corrupted on start up.
I know that the HEX file must have a CRC number in it that can be used for this right?
Ok with all that said this is what I’m look for.
On start up read the ROM image and verify it against a check sum number.
An help would be greatly appreciated!
Tom |
|
 |
chas
Guest
|
| Rom Checksum |
| Posted: Tue Nov 11, 2003 11:42 am |
|
|
| Do a search by entering "rom and checksum" in the box, without the quotes. You will find a post by stevev(?) from February that asks this same question, but has what looks like a good reply. |
|
|
stevev
Joined: 11 Nov 2003
Posts: 4
Location: Portland, Oregon
|
| Checksum ROM image |
| Posted: Tue Nov 11, 2003 12:07 pm |
|
|
I never received any responses that defined what the #ID CHECKSUM directive of the compiler does, and all my attempts at finding out by experiments failed. Finally I just gave up....
If you get any answers please share them with this group as I believe verifying the flash ROM at startup must be a common requirement for many embedded systems (it certainly is for avionics projects).
Good luck! -steve- |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Tue Nov 11, 2003 12:54 pm |
|
|
Straight from the manual:
| Quote: |
#ID "filename"
#ID CHECKSUM
Elements: Number16 is a 16 bit number, number is a 4 bit
number, filename is any valid PC filename and
checksum is a keyword.
Purpose: This directive defines the ID word to be programmed
into the part. This directive does not affect the
compilation but the information is put in the output file.
The first syntax will take a 16-bit number and put one
nibble in each of the four ID words in the traditional
manner. The second syntax specifies the exact value
to be used in each of the four ID words.
When a filename is specified the ID is read from the file.
The format must be simple text with a CR/LF at the
end. The keyword CHECKSUM indicates the device
checksum should be saved as the ID.
Examples: #id 0x1234
#id "serial.num"
#id CHECKSUM
Example Files: ex_cust.c
|
So all you have to do is compute the checksum and compare it with what is stored in the ID |
|
|
stevev
Joined: 11 Nov 2003
Posts: 4
Location: Portland, Oregon
|
|
| Posted: Tue Nov 11, 2003 4:45 pm |
|
|
| Mark wrote: | Straight from the manual:
| Quote: |
#ID CHECKSUM
The keyword CHECKSUM indicates the device
checksum should be saved as the ID.
|
So all you have to do is compute the checksum and compare it with what is stored in the ID |
Yes, I understand. My unanswered question is: What computation is used by the compiler to calculate the #ID CHECKSUM value? Without knowing the algorithm the comiler uses, how can we duplicate it at run time?
Unless I made some mistakes (likely), It did not match my attempts at: XOR, 8-bit summing, the code shown in the example, etc. I never came up with the same result as the compiler! Thanks -steve- |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Tue Nov 11, 2003 5:22 pm |
|
|
Did you try something like this:
| Code: |
checksum = 0;
for(i=0;i<32768;i++)
checksum^=read_program_eeprom(i);
|
|
|
|
stevev
Joined: 11 Nov 2003
Posts: 4
Location: Portland, Oregon
|
| Checksum ROM image |
| Posted: Tue Nov 11, 2003 7:52 pm |
|
|
I tried code like the following, but still it doesn't match the compiler constant produced by #ID CHECKSUM:
| Code: |
// -- get checksum from ID bits (set by compiler/linker at build time)
romChecksum = getenv("ID");
// -- remove config word: HS WDT NOPUT NOPROTECT BROWNOUT NOLVP NOCPD WRT
romChecksum -= 0x3F7E;
flashChecksum = 0; // initial checksum value
// -- compute checksum of FLASH program ROM to verify program good
for (flash=0; flash<getenv("PROGRAM_MEMORY"); flash++)
flashChecksum += read_program_eeprom(flash);
flashChecksum = ~flashChecksum; // 1's complement
flashChecksum &- 0x3ff; // mask to 14-bits
// -- show error message and halt if checksum's don't match!!
if (flashChecksum != romChecksum)
{
// -- checksum bad --
}
|
|
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Tue Nov 11, 2003 8:41 pm |
|
|
| I have been playing around a bit with it. I haven't figured it out yet but it does appear to be some sort of 'sum'. |
|
|
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| I can’t even get the number out of the compiler |
| Posted: Thu Nov 13, 2003 7:38 am |
|
|
Last night I compiled some code with #ID CHECKSUM and with out it.
I compared the two list files and the only thing that I found is the REM line that had #ID CHECKSUM on it.
So does the compiler only put the checksum number in the HEX file?
Mark did you have time to look at this some more?
I would really like to get this working.
Thanks All
Tom |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Thu Nov 13, 2003 7:41 am |
|
|
| Yes it is only stored in the hex file. No I haven't had time to play with it anymore. I will when I have the time unless someone else beats me to it. |
|
|
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| testing today |
| Posted: Thu Nov 13, 2003 3:54 pm |
|
|
I have now had time to go back and research the form and look at stevev?s old post from the Feb. time frame. I have also read the microchip TB026 that PCM programmer had posted.
http://www.microchip.com/1000/suppdoc/appnote/all/tb026/index.htm
With all of that said I have been working this all most all day today and have got no place on it.
I took stevev code that he posted and used it as a starting point.
This is the code that I'm using.
| Code: |
int1 rom_check(){
int16 romChecksum,flashChecksum,flash;
// -- get checksum from ID bits (set by compiler/linker at build time)
romChecksum = getenv("ID");
// -- remove config word: HS WDT NOPUT NOPROTECT BROWNOUT NOLVP NOCPD WRT
//romChecksum -= 0x3F7E;
fprintf(Land, "%LX\n", romChecksum);
flashChecksum = 0; // initial checksum value
// -- compute checksum of FLASH program ROM to verify program good
for (flash=0; flash<getenv("PROGRAM_MEMORY"); flash++)
flashChecksum += read_program_eeprom(flash);
fprintf(Land, "%LX\n", flashChecksum);
flashChecksum = ~flashChecksum; // 1's complement
flashChecksum++; // Added one to the 1's complement to get the 2's complement
//Not used 16 bit part flashChecksum &- 0x3ff; // mask to 14-bits
fprintf(Land, "%LX\n", flashChecksum);
// -- show error message and halt if checksum's don't match!!
if (flashChecksum != romChecksum){
// -- checksum bad --
return False;}
else{
// -- CheckSum is OK --
return True;}}
|
The numbers that this code output are
romChecksum = 0x498c
flashChecksum = 0x985f
flashChecksum 2's Comp. = 0x67a1
And this is the line of the HEX file that I think is the checksum line ':0800000005F008F00EF00EF00F'.
If I replace this 'getenv("PROGRAM_MEMORY")' in the for loop of the read flash with 0x7fff.
The numbers will be
romChecksum = 0x5dd4
flashChecksum = 0xa629
flashChecksum 2's Comp. = 0x59d7
And this is the line of the HEX file that I think is the checksum line ':0800000005F009F008F00CF00F'.
One thing that I have made note of is the numbers in the hex file and the 'romchecksum' number are not even close to each other ?
So I don't know what to think about this now!
Tom |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Thu Nov 13, 2003 9:22 pm |
|
|
Okay I figured it out. Now the bad news. It is worthless. According to CCS, they following the Microchip Programming Specification. They didn't! It appears they add all the bytes programmed and then add an additional 2 0xFF's to it. Note that I said all the bytes programmed meaning what is listed in the HEX file. Kinda hard to figure this out from the micros point of view since it sees all program locations! Thank goodness for TiVo  Now I can get back to the important stuff of watching a little TV |
|
|
Darren Rook
Joined: 06 Sep 2003
Posts: 287
Location: Milwaukee, WI
|
|
| Posted: Fri Nov 14, 2003 8:52 am |
|
|
I'm pretty sure that you can't use getenv("ID") to get the checksum set by #ID CHECKSUM because the CHECKSUM is calculated after the code is generated - so the CHECKSUM isn't calculated by the time you use getenv("ID").
I don't recall two 0xFFs being added.
Here is code I had a few months ago that worked:
| Code: |
#include <18F452.H>
#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#id checksum
main() {
int32 address;
unsigned long CheckSum = 0x0000;
unsigned long temp;
long id_val[4];
long h_id_val[4];
h_id_val[0]=make16(read_program_eeprom(0x200001),read_program_eeprom(0x200000));
h_id_val[1]=make16(read_program_eeprom(0x200003),read_program_eeprom(0x200002));
h_id_val[2]=make16(read_program_eeprom(0x200005),read_program_eeprom(0x200004));
h_id_val[3]=make16(read_program_eeprom(0x200007),read_program_eeprom(0x200006));
printf("\r\n\r\nCalcing....\r\n");
// Calculate checksum of all program flash.
for (address = 0; address < getenv("PROGRAM_MEMORY")*2; address+=2)
{
temp = make16(read_program_eeprom(address+1), read_program_eeprom(address));
CheckSum += temp;
}
// Include all configuration words (as 16 bit numbers) into checksum.
for (address = 0x300000; address <= 0x30000C; address+=2)
{
temp = make16(read_program_eeprom(address+1), read_program_eeprom(address));
CheckSum += temp;
}
id_val[0]=((checksum/0x1000) % 16) | 0xF000;
id_val[1]=((checksum/0x100) % 16) | 0xF000;
id_val[2]=((checksum/0x10) % 16) | 0xF000;
id_val[3]=((checksum) % 16) | 0xF000;
printf("HEX 0: %LX 1: %LX 2: %LX 3: %LX",h_id_val[0],h_id_val[1],h_id_val[2],h_id_val[3]);
printf("\r\nPIC 0: %LX 1: %LX 2: %LX 3: %LX\r\n",id_val[0],id_val[1],id_val[2],id_val[3]);
while(TRUE) {}
}
|
|
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Fri Nov 14, 2003 9:51 am |
|
|
I tested this on a newer version of the compiler than I was using last night and it works fine. Apparently this was fixed sometime between 3.091 and 3.144  |
|
|
Tom-H-PIC
Joined: 08 Sep 2003
Posts: 105
Location: New Castle, DE
|
| New Code Thanks All |
| Posted: Sun Nov 16, 2003 11:42 am |
|
|
Thanks Darren, Mark, Stevev and All that have helped on this.
I will be out all next week but as soon as I get a chance to test this new code from Darren I will report back.
Thank you Darren for the code.
Tom |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
