flash self test - HCS08SG8

[jag]

Hi,
for a (automotive) project I need to do a flash self-test at power up in order to be sure that the flash is not corrupted.
I'm using a HCS08SG8 processor (CW 6.1).
I already found the checksum.c library and made it works.

Now I have to understand which CRC or checksum is better. Or course I need either speed and safety.

As far as I understand CRC32 is the best, then CCITT, 16, 8 and other checksum (ADD,XOR,...).
But I have to explain my choice (for the moment is CCITT) to my superior and to the customer.

For the speed is easy, but for the safety I'm completely lost. All the theory I read until now speak about Hamming Distance, or the number of bits that can be corrupted at the same time.
So the question is: there's is some statistical analysis on flash corruption I can use to explain why I used CCITT instead of CRC16 (or CRC32)?

Thanks

Bye Jack


Message Edited by jag on 2008-08-12 10:44 AM

Message Edited by NLFSJ on 2008-08-13 08:59 AM

[SZheng]

Can you tell me how you made it work using checksum.c?

I need to test flash too. But I have no idea how to use checksum comparison? it is easy to calculate new checksum, but how to know teh checksum in teh file?

My email address: szheng@amerigon.com

Thanks a lot!

Simon

[egoodii]

Using CodeWarrior, those commands above starting with CHECKSUM are tacked onto the end of your PRM file and tell the linker to create said checksum by that means and put in that place in the s19 hex file, in this case at the end of 'code space' to simply make the total result come out to zero.  This example is all for a 4K part, using the whole ROM space in one application.  I actually use this process as part of a bootloader/application split of ROM space so I have two checksums and two CRC processes, one to check the bootloader and one to check the application space for valid code to run.  This works well with the CodeWarrior IDE abilities to 'preserve memory' sections during code-programming at debugger entry so that the application section can update while preserving the entirely independent bootloader operation.

[bigmac]

Hello Jack,

A simple way of considering the issue - the device you are using contains 8K bytes of flash, or 64K bits - your code size will never exceed this amount.  Since a 16-bit CRC value has nearly 64K different values, a particular value should represent a unique combination of bits within flash, so should be suitable for this application.  Either method of 16-bit CRC generation should be equally as effective, only the polynomial will differ for each case.

For larger amounts of code, there would be the possibility that a CRC value could represent two or more different combinations within flash.  Should the code size become much larger, you would need to consider the use of 32-bit CRC.

Regards,

Mac

[jag]

Ok thanks.

After some speed test I think I will use the CRC-CCITT without the LookUpTable (92 msec with, 127 without).

Bye Jack

[egoodii]

I'm late getting to this, but searchers may find it useful.

I found this slick trick for calculating CCITT CRC16 on the web some time back, and it computes the CRC a BYTE at a time with NO tables, and in this loop on an S08 with a 16MHz bus clock runs at 5uS/byte!  That means the whole 8K in 40ms.  The whole routine is 80 bytes.  Don't ask me how it works, someone with better boolean math skills than mine must've come up with it!

#pragma DATA_SEG __SHORT_SEG MY_ZEROPAGE   //Direct-access vars

static uint8_t i;

static union{
   struct{
       uint8_t hi;           //Big endian
       uint8_t lo;
   } byte;
   uint16_t word;
} crc,addr;
#define FLASH_START 0xF000
#define FLASH_END 0xFFAD     //Stop before NVTRIM storage

//Compute CRC of upper FLASH
    crc.word = 0xFFFF;  //Seed
    addr.word = FLASH_START - 0x0100; //Start, pre-subtract extra hi-byte inc
    do{
        __RESET_WATCHDOG();                       //Kick the Dog about every ms
        ++addr.byte.hi;
        do{                                       //Bytewise CRC, about 5uS/byte!
            i = *((u8_t *)(addr.word)) ^ crc.byte.hi;
            crc.byte.hi  = crc.byte.lo;
            crc.byte.lo  = i;
            crc.byte.lo ^= crc.byte.lo >> 4;
            crc.byte.hi ^= crc.byte.lo << 4;
            crc.word    ^= crc.byte.lo << 5;
        }while( (addr.word <= FLASH_END) && (++addr.byte.lo != 0) );

                                                                           //go 256 bytes at a time
    }while(addr.word <= FLASH_END);               //Until the end
//crc.word better end up zero!

This goes in conjuction with a linker block in the prm file:

CHECKSUM
    CHECKSUM_ENTRY METHOD_CRC_CCITT
        OF READ_ONLY 0xF000 TO 0xFFAB
        INTO READ_ONLY 0xFFAC SIZE 2
        UNDEFINED 0xFF
    END
END

[egoodii]

Bug Alert!  FLASH_END needs to be one less to account for increment after test!  Worked fine as long as fine-trim was zero...