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.

TMS320F280025: VCRC Library Incorrect Result

Part Number: TMS320F280025

I'm struggling to get the VCRC to give me correct values.  Not sure what I'm doing wrong since I can't view VCRC registers with the debugger.

When I poach from VCU0 example code to do the CRC with the CPU everything works great:

uint16_t testArray3[] = {0x0100, 0x0302, 0x0504, 0x0006};

void genCRC8Table()
{
  register uint16_t i;
  register uint16_t j;
  register uint16_t crc8_accum;


  for ( i = 0; i < 256;  i++ )
  {
    crc8_accum = i;
    for ( j = 0; j < 8;  j++ )
    {
      if ( crc8_accum & 0x80L )
        crc8_accum = ( (crc8_accum << 1) & 0xff ) ^ 0x31;
      else
        crc8_accum = ( crc8_accum << 1 ) & 0xff;
    }
    crc8_table[i] = crc8_accum;
  }
}

//  C- function to get the 8-bit CRC
//
// \param The initial value of crc, in case the message has been
//  chopped into several parts, you can use the crc8 of the previous
//  segment as the init value for the current segment crc8 calculation
//  until the final crc is derived.
// \param Address of the message buffer
// \param Parity of the first message byte, i.e. whether its on an even
//  or odd address
// \param Length of the message in bytes
//
// Calculate the 8-bit CRC of a message buffer by using the lookup table,
// crc8_table to get the CRC of each byte.
//
// \return CRC result
//
uint16_t getCRC8_cpu (uint16_t input_crc8_accum, uint16_t * msg, CRC_parity_e parity,
    uint16_t rxLen)
{
  register uint16_t i;
  register uint16_t j;
  uint16_t crc8_accum;
  int16_t *pdata;

  crc8_accum = input_crc8_accum;
  pdata = (int16_t *)msg;

  for (j = 0; j < rxLen; j++, parity++)
  {
    i = crc8_accum ^ (__byte(pdata, parity));
    crc8_accum = crc8_table[i];
  }

  return (uint16_t)crc8_accum;
}



    genCRC8Table();
    CRC.crcResult = getCRC8_cpu(0, testArray3, CRC_parity_even, 7);

This yields the correct result which is 0xA4 (notice my polynomial is 0x31).

When I try to do the same using the VCRC I get a result of 0x8000.

    // Step 1: Initialize CRC objects
    CRC.seedValue      = 0x00;                        //enter the seed value for CRC computation
    CRC.nMsgBytes      = 7;                                 //enter the number of bytes on which the CRC is to be computated
    CRC.nMsgBits       = 0;                                 //enter the number of bits for CRC computation
    CRC.parity         = CRC_parity_even;                   //choose to compute CRC for lower byte(8 bits) first or upper byte first based on the parity value
    CRC.crcResult      = 0;                                 //CRC result would be stored in the location
    CRC.pMsgBuffer     = 0;                                 //pointer to the message buffer
    CRC.polynomial     = 0x0031;                      //user polynomial
    CRC.polySize       = SIZE_8_BITS;                       //polynomial size
    CRC.dataSize       = SIZE_8_BITS;                       //data size
    CRC.reflected      = 0;                                 //Whether the computation is to be done from LSB or MSB, if CRC.reflected = 1 then the data bytes would be flipped before CRC computation
    CRC.init           = (void (*)(void *))CRC_init8Bit;   //initialize the CRC routine by context save and context restore calls
    CRC.run            = (void (*)(void *))CRC_runConfigPolyBytes;  //point to the C routine or lookup table for CRC computation through software

    // Step 2: Initialize the handle
    handleCRC = &CRC;


    CRC.nMsgBytes   = 7;                                   //enter the number of message bytes
    CRC.pMsgBuffer  = testArray3;
    CRC.run(handleCRC);

Any idea what I'm doing wrong?

  • Trey,

    I'm not able to find anything obviously wrong with your implementation.

    One area of suspicion was the data buffer and the MSB-LSB ordering, but even that seems fine. The C implementation relies on the __byte intrinsic and use parity to index into the array, so the order of computation (I expect) would be 0x00 0x01 0x02 0x03 0x04 0x05 0x06. Likewise, the order of computation in the VCRC case would be LSB first, then MSB, so 0x00 0x01 0x02 0x03 0x04 0x05 0x06.

    Just to absolutely rule this out as a possible issue - maybe try swapping the byte order for the VCRC computation and see what happens.

    Also, you mention 0xA4 is the correct result - can you point me to the online calculator tool you are using to arrive at this conclusion (and the corresponding settings for your data set and CRC)?

    Thanks,

    Sira