This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F5659: Driverlib example for CRC-16 gives wrong result?

Part Number: MSP430F5659


When I run the driverlib example crc_ex1_buildSignature.c the result returned using the following code the result is 0xA1A3.  This doesn't match with any online CRC check using the same polynominal 0x1021.  The result from those websites is: 0x2378 .  What am I missing here?

    uint16_t crcSeed = 0x0000;

    uint16_t data[] = {0x0001,0x0002,0x0003,0x0004,0x0005,0x0006,0x0007,0x0008,0x0009};\\

    //Set the CRC seed

    CRC_setSeed(CRC_BASE,

        crcSeed);

    for (i = 0; i < 9; i++)

    {

        //Add all of the values into the CRC signature

        CRC_set16BitData(CRC_BASE,

            data[i]);

    }

    //Save the current CRC signature checksum to be compared for later

    crcResult = CRC_getResult(CRC_BASE);

  • The CRC is a bit by bit thing so bit order matters and can cause confusion with results. I see that the library has functions to set a reversed bit order for the input bits and/or the result. Try different combinations and you should hit on one that matches.

  • Thanks.  I can't get it to work using CRC_set16BitDataReversed() even though I see the register has reversed the byte.  For instance, using a single byte like 0x0009 will not correspond to the calculators online.  When I use the CRC_set16BitDataReversed function it still won't work using etither  CRC_getResult() or CRC_getResultBitsReversed.  However, if I initially reverese the byte myself;  using 0x9000 instead, then CRC_getResult() will yield the proper result.

  • Thanks.  I can't get it to work using CRC_set16BitDataReversed() even though I see the register has reversed the byte.  For instance, using a single byte like 0x0009 will not correspond to the calculators online.  When I use the CRC_set16BitDataReversed function it still won't work using etither  CRC_getResult() or CRC_getResultBitsReversed.  However, if I initially reverese the byte myself;  using 0x9000 instead, then CRC_getResult() will yield the proper result.

     

    Followup:  I discovered my error.  If working with 8 bit numbers use the 8 bit functions like CRC_set8BitDataReversed().  The above 16 bit functions was reversing 0x0009 to 0x0900 which was causing all the grief.  Makes perfect sense!

  • Hi,

    The issue seems solved. I am going to close this thread. 

    Best regards,

    Cash Hao

**Attention** This is a public forum