#ID CHECKSUM - ID Location Registers in PIC18F

[robroy_1]

Hello;

I have looked at prev posts on this and have not found my answer. More than likely I have not looked hard enough.

I am using CCS v3.178 compiler, MPLAB 6.51, ccsmplab plugin v6.
I have PIC18F1320.
I have inserted #ID CHECKSUM into source code
I have the following resultant lines for address 200000 hex.

:020000040020DA
:0800000001F009F007F00AF01D

In MPLAB, my checksum is 0xd729.

How is (and what are the dependencies) the CCS checksum calculated?
Is the CCS checksum dependent on position in the file of the #ID CHECKSUM statement?
Is there a formula to convert between the two?

I can not figure the relation between MPLAB and CCS. Any advice?

THanks...

[PCM programmer]

Did you read this huge thread where they go on and on
about this issue ? It's two pages long.
http://www.ccsinfo.com/forum/viewtopic.php?t=17536

[robroy_1]

BTW, read the thread. Doing it from inside the program will probably work by using romCheck=getenv("ID")?

First, the format of the hex file:
In extended addressing mode I have not found any examples that allow me to reverse engineer the bits as I have witnessed them for the PIC18F.

In the manual you state that #ID number, number where number is a 4 bit number. Well if I put 8 bits of number in there they all come out

for #ID 0xdd, 0x77, 0x22, 0x99 I get
:020000040020DA
:08000000DD00770022009900...

for #ID 0xd, 0x7, 0x2, 0x9 I get
:020000040020DA
:08000000D000700020009000...

Back to my current problem of understanding the hex file, since the bytes in the file are low byte, high byte ordered, if I reverse them to look at them so i can read them I get from my hex file

:020000040020DA
:0800000001F009F007F00AF01D

F001 F009 F007 F00A

How is this related to my checksum as shown in MPLAB as 0xd729?

Please help!

Thx.

[PCM programmer]

I don't really want to get involved in this. The participants on that
thread posted lots of code, and they still couldn't completely agree
that the problem was solved. Hopefully one of them will reply.

[robroy_1]

In the last post, I noted that the data values are separated

:020000040020DA
:08 0000 00 01F0 09F0 07F0 0AF0 1D

?indicating that there appear to be 16 bits in the id memory locations 200000..200007?

I can and will test the #id number 16 and the #id number,number, number in the morning to validate that. That would prove that the id locations are really program memory flash for the PIC18FXXXX. Then all I have to do is figure the relation between the CCS Compiler and MPLAB IDE checksums.

[robroy_1]

Let me go back and give a little more detail first.....

My goal is to be able to identify the current programming of the processor via a run time function that will read the same checksum value that is reported by the MPLAB IDE. I am NOT interested in performing a run time validation of the program memory. I am only interested in retrieving the checksum stored in the ID location bits to report to the user at run time.


The CCS version is 3.178 for the PIC18F1320 and I noted that there was a fix; 3.191 The read/write program_memory functions missing from some parts is now back...perhaps that is a partial fix for what lies below.
-------------------------------------------------------------------------------

I used the #ID CHECKSUM in the source code. I looked at my hex file for the extended address records for the ID locations 0x200000..0x200007

:020000040020DA
:08 0000 00 01F0 09F0 07F0 0AF0 1D
-----------------------------------
NN AAAA TT DDDD DDDD DDDD DDDD CC -byte descriptors
1122 3344 5566 7788 -id location

It looks like the intention was to write?

:020000040020DA
:08 0000 00 1F00 9F00 07F0 0AF0 1D
-----------------------------------
NN AAAA TT DDDD DDDD DDDD DDDD CC -byte descriptors
1122 3344 5566 7788 -id location

which would make NOP's out of these bytes as per Microchip

----(FROM 39592b.pdf for PIC18F1X20)---------------------
5.1 ID Locations
A user may store identification information (ID) in eight
ID locations mapped in 200000h:200007h. It is recommended
that the most significant nibble of each ID be 0Fh. In doing
so, if the user code inadvertently tries to execute from
the ID space, the ID data will execute as NOP.
----------------------------------------------------------

The checksum that MPLAB V6.51 IDE reports for this file is 0xd729. These are the following things that need clarification:

0. The GETENV("ID") is only a compiler time function which hard codes the result into the program? I checked the list file to see what the following does:

romChecksum = getenv("ID");

and noted that it just cleared two adjacent bytes. This would indicate that it did not evaluate the previous line in code. Here is the list clipping for this

.................... romChecksum = getenv("ID"); // this depends on the #ID CHECKSUM statement in source
02AC: CLRF 0C
02AE: CLRF 0B
.................... for (i=0;i<16;i++)

No table read or program memory read there....!


1. Does the CCS compiler place the same checksum in the ID locations as the one that is reported in the MPLAB IDE? If it is not the same checksum then how is it produced?

2. How is the checksum placed (distributed?) into the ID memory locations? (because it looks like a two byte checksum would fit into the first memory location <validated that theory this morning and found that passing 16 bit numbers gives consecutive data where passing 8 bit numbers has pad bytes in between the data bytes) and does not need to be spread across multiple bytes)

3. Assuming that the answer to #1 = yes, and the checksum is placed in the lower byte of the first four memory locations; what is the F0 doing in the high byte of the ID locations? Is this an incorrect implementation of trying to pad the upper nibble with 0xF so it then would be interpreted as a NOP?

[robroy_1]

Just updating the post, the compiler update did not change anything.

[robroy_1]

Thanks to CCS tech support for the following:

The #ID CHECKSUM directive spreads the checksum as
follows in memory <PIC18F1X20>:

0x200000....checksum hexadecimal character #1 in the lower nibble
0x200001....pad
0x200002....checksum hexadecimal character #2 in the lower nibble
0x200003....pad
0x200004....checksum hexadecimal character #3 in the lower nibble
0x200005....pad
0x200006....checksum hexadecimal character #4 in the lower nibble
0x200007....pad

The checksum data is not a character but a nibble value. If you need the checksum value loaded into a 16 bit location:

int16 checksum; //
int8 i;

checksum=0;
for(i=0;i<=3;i++)
checksum=checksum*16+(read_program_eeprom(0x200000+i*2) & 15); // mask so only lower nibble is used.

Then one can load the programmed checksum into EEPROM, then run the routine to verify the program load. I assume that one could re-write the ID location bytes after a bootstrap loader finished.

Now, if I can only ..........

RR