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.

MSP430FR5994: CRC32 Value Does Not Match Expected Value

Part Number: MSP430FR5994

I'm attempting to use the MSP430's CRC32 hardware block and the example code provided in the Resource Explorer. The user guide for the MSP claims that the CRC32 module uses the CRC-ISO3309 polynomial, but any calculations I've done with the MSP yield wildly different results when compared to an external calculator (i.e., https://crccalc.com/, 

  • It looks like my initial post got mangled by the editor. Here's the full text:

    I'm attempting to use the MSP430's CRC32 hardware block and the example code provided in the Resource Explorer. The user guide for the MSP claims that the CRC32 module uses the CRC-ISO3309 polynomial, but any calculations I've done with the MSP yield wildly different results when compared to an external calculator (i.e., https://crccalc.com/, Python's zlib module). I've checked bit order and played with all sorts of values, but I've been unsuccessful so far.

    Is there something I'm missing when it comes to generating a reproducible CRC32 value on the MSP430?

    For example, when I initialize CRC32INIRESW0 and CRC32INIRESW1 with 0xFFFFFFFF as instructed in the example, and provide an input to CRC32DIRBW0/1 of 0x00000000, I expect to get 0x2144DF1C, but the CRC32 hardware outputs 0xDEBB20E3 from CRC32RESRW0/1. Similarly, with a seed of 0xFFFFFFFF and input data of 0x11111111, I expect to get a result of 0xED6C2543, but the MSP returns 0x0949ED5E.

  • It *was* just me!

    Two key things:

    My code looks like this:

    CRC32DIW0 = data & 0x0000FFFF;
    CRC32DIW1 = data >> 16;
    
    uint32_t CRC32_result = ((uint32_t) CRC32RESRW0 << 16);
    CRC32_result |= ((uint32_t) CRC32RESRW1 & 0x0000FFFF);

    1) I had to include an XOR at the end (CRC32_result ^= 0xFFFFFFFF;) to match the ISO3309 spec implementations in other languages.

    2) The byte order ended up flipped (i.e., 0x44332211 given to the MSP becomes 0x11223344 when given to a different calculator). I'm guessing this is a mix of the sample code and little-endianess.

**Attention** This is a public forum