• AVR Freaks

Hot!CRC Checksum for program integrity

Author
andyrichmond
Senior Member
  • Total Posts : 134
  • Reward points : 0
  • Joined: 2003/11/07 12:36:34
  • Location: UK
  • Status: offline
2005/09/09 02:22:22 (permalink)
0

CRC Checksum for program integrity

Hi All,

I have seen from past posts various people using checksuming techniques in order to verify the integrity of program code at, say, power up.

There have been various suggestions and references to code that can be used to calculate these checksums, but what is not as obvious to me is how the reference checksum is generated. The most basic form of checksum used by MPLAB IDE is obvious of course, but what about other forms of checksuming, CRC16 or CRC32 for example?

It would seem to me that a separate application program is required which would parse the output HEX file, extract the program memory values and CRC them accordingly? The resulting CRC can them be embedded into the program code.

Could anyone indicating that this is the route they have taken or possible alternatives?

Thanks,
Andy
#1

12 Replies Related Threads

    Guest
    Super Member
    • Total Posts : 80503
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: CRC Checksum for program integrity 2005/09/09 03:01:45 (permalink)
    0
    hey Andy

    first u have to make a program in PC to calculate the CRC of hex prgram then store it last locations of program then burn the controller
    and in power on u can read these hex bytes and then calculate the crc again and match with ur stored CRC
    #2
    andyrichmond
    Senior Member
    • Total Posts : 134
    • Reward points : 0
    • Joined: 2003/11/07 12:36:34
    • Location: UK
    • Status: offline
    RE: CRC Checksum for program integrity 2005/09/09 03:06:49 (permalink)
    0
    Hi,

    Thanks for your reply.

    Your suggestion is pretty much as I suspected.

    I'm still curious if anyone has developed an alternative way.

    Cheers,
    Andy
    #3
    Guest
    Super Member
    • Total Posts : 80503
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: CRC Checksum for program integrity 2005/09/09 06:08:49 (permalink)
    0
    Alternatively (instead of running an external CRC on the HEX file), you can have both the CRC check and the CRC generator routines in your code. During development, when you have verify o.k., you can send commands or set flags in eeprom, or just have your code test some flag in the program memory and compute the CRC and store it in a program memory table. So you will have automatic CRC generation and then subsequently the startup code runs CRC verification on each powerup. To avoid SEU (single event upset) you can have your 'flag' to be a program memory word that is checked against a XOR mirror and must return 0 or something like that.
    #4
    virtuA
    Starting Member
    • Total Posts : 61
    • Reward points : 0
    • Joined: 2004/08/05 22:31:45
    • Location: France
    • Status: offline
    RE: CRC Checksum for program integrity 2005/09/09 06:37:35 (permalink)
    0
    hi,
    For CRC16 Program :

    http://perso.wanadoo.fr/virtua.area/info/CRC16.htm

    and for PIC routine :

    unsigned int Crc16(unsigned char *Adresse_tab , unsigned char Taille_max)
    {
    unsigned int Crc = 0xFFFF;
    unsigned int Polynome = 0xA001;
    unsigned char CptOctet = 0;
    unsigned char CptBit = 0;
    unsigned char Parity= 0;

    Crc = 0xFFFF;
    Polynome = 0xA001; // Polynôme = 2^15 + 2^13 + 2^0 = 0xA001.

    for ( CptOctet= 0 ; CptOctet < Taille_max ; CptOctet++)
    {
    Crc ^= *( Adresse_tab + CptOctet); //Ou exculsif entre octet message et CRC

    for ( CptBit = 0; CptBit <= 7 ; CptBit++) /* Mise a 0 du compteur nombre de bits */
    {
    Parity= Crc;
    Crc >>= 1; // Decalage a droite du crc
    if (Parity%2 == VRAI) Crc ^= Polynome; // Test si nombre impair -> Apres decalage à droite il y aura une retenue
    } // "ou exclusif" entre le CRC et le polynome generateur.
    }
    return(Crc);
    }


    ++

    (Sorry for my bad english)
    #5
    Guest
    Super Member
    • Total Posts : 80503
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: CRC Checksum for program integrity 2005/09/09 14:14:32 (permalink)
    0
    Unfortunately the MPLAB checksum is often a pain because of things like the config byte (after 'appropriate' masking!) and ID locations getting added in under certain conditons (like having protected blocks. I also seem to recall that it wasn't getting calculated right unless the .lnk had a FILL specification to fill unused program memory with 0xffff. But that was long ago, and several releases of MPLAB IDE ago,so if it was true, it may not be the case now.

    Its also a pain to get the value inserted automatically into the program.

    The closest way is to have MPLAB use the checksum as the ID locations. But then to compare this to a powerup recalculated checksum, you have to combine the ID locations, the least significant 4 bits of the first 4 bytes of the ID,in bigendian order to get the checksum.

    Personally when I checksum a code area, I have two reserved words. One for the checksum, and one for the compliment of the checksum. This is initialized with 0x0000 in one, and 0xffff in the other. Once the real checksum is calculated and inserted, the sum of the checksum and the complement is the same as the sum of 0x0000 and 0xffff. Therefore you don't have to exclude the locations holding the checksum from the calculation.

    Its too bad MPLAB doesn't have something closer to a real makefile so that a call to the checksum calculation/insertion program could be done after each link.
    #6
    andyrichmond
    Senior Member
    • Total Posts : 134
    • Reward points : 0
    • Joined: 2003/11/07 12:36:34
    • Location: UK
    • Status: offline
    RE: CRC Checksum for program integrity 2005/09/13 05:32:04 (permalink)
    0
    Hi,

    Thanks for the suggestions. I'll ponder this problem some more.

    Cheers,
    Andy
    #7
    Texomaboater
    New Member
    • Total Posts : 2
    • Reward points : 0
    • Joined: 2009/12/16 10:52:39
    • Location: 0
    • Status: offline
    RE: CRC Checksum for program integrity 2010/03/30 06:26:27 (permalink)
    0
    Hi:
     
    My Program CRC is not working-I read all zeros from program memory (even though code protection is turned off).
    (I assume that I can start at memory address zero and continue to the end of the program length).
     
    Thanks in advance for the help!
     
    Here are the details...
    Processor - PIC18F85J90
     

    #pragma config CP0 = OFF
     
     
     

    unsigned int Crc16()
    {
      unsigned long i;
      unsigned char byte;
      unsigned char * lPointer;
      unsigned int TempCRC16;
      unsigned int FinalCRC16;
      lPointer = 0;
      byte = *lPointer;
      TempCRC16 = crc16_add ( byte, SEED_16);
      for ( i = 1; i < 0x2c80; i++ )
      {
         lPointer ++;
         byte = * lPointer;
        __LOG (0, byte);
        TempCRC16 = crc16_add ( byte, TempCRC16);
      }
      FinalCRC16 = TempCRC16;
      return FinalCRC16;
    }
     
     
    #8
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11982
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    RE: CRC Checksum for program integrity 2010/03/30 10:14:57 (permalink)
    0
    I read all zeros from program memory

    You haven't said which compiler you're using, but it looks like you're reading RAM, not program memory.
    #9
    Texomaboater
    New Member
    • Total Posts : 2
    • Reward points : 0
    • Joined: 2009/12/16 10:52:39
    • Location: 0
    • Status: offline
    RE: CRC Checksum for program integrity 2010/03/30 10:17:03 (permalink)
    0
    Thx for the reply.
     
    I am using the Microchip C18 compiler.
     
    So... what address does code start at?
     
    BTW, if I turn on Code Protection, will I still be able to run this test?
     
    Thx,
     
    Jeff
    #10
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11982
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    RE: CRC Checksum for program integrity 2010/03/30 10:26:40 (permalink)
    0

    ORIGINAL: Texomaboater

    So... what address does code start at?

    It starts at address 0, just like RAM; the PIC is a Harvard architecture. You'll have to use the "rom" keyword to access program memory, as described in the compiler's documentation.

    BTW, if I turn on Code Protection, will I still be able to run this test?

    You should be able to, but that will depend on which types of code protection your PIC supports and which types you enable.
    #11
    markm23
    Starting Member
    • Total Posts : 28
    • Reward points : 0
    • Joined: 2019/11/21 12:51:59
    • Location: 0
    • Status: offline
    Re: RE: CRC Checksum for program integrity 2020/08/03 15:54:22 (permalink)
    0
    In the newer generation of PIC16F (I'm currently in a year-long project with PIC16F15356), there are two kinds of code protection. There is one "CP" bit in the Configuration Words that basically disables every ICSP programmer function but bulk erase.  E.g., when this bit is set, if you try to read any part of the Flash with the programmer, it reads all zeroes. However, it leaves the program _in_ the Flash capable of reading or writing Flash via the NVM registers. Programming has no effect. Bulk erase still works - setting every "read/write" part of the flash to 0x3FFF, including erasing the CP bit. So you can erase and reprogram the chip, but you can't read what was there before the erase, and you can't slip in a patch to use the NVM registers to get around the protection.
     
    There are also Configuration Words protection bits for each area of the Flash, which restrict the software _in_ the Flash from writing selected sections. E.g., I have the bootloader partition and the configuration words protected; neither the bootloader nor the application can change these, but the programmer/debugger has easy access. The Application partition and the User ID are not protected because the bootloader has to change them to update the Application. The SAF (Flash being used in place of EEPROM) is unprotected because the Application writes to it. And I have to make sure the Application software can't run amok and write over itself, because there's only one set of Configuration Words for the Bootloader and the Application.
    #12
    ric
    Super Member
    • Total Posts : 28386
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: RE: CRC Checksum for program integrity 2020/08/03 19:05:41 (permalink)
    +2 (2)
    Bit late for the other posters ten years later.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #13
    Jump to:
    © 2020 APG vNext Commercial Version 4.5