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 库结果不正确

Guru**** 2609895 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1582289/tms320f280025-vcrc-library-incorrect-result

器件型号:TMS320F280025


我努力得到 VCRC 来提供正确的值。  不确定我做了什么错误、因为我无法使用调试器查看 VCRC 寄存器。

当我从 VCU0 示例代码发出来使用 CPU 执行 CRC 时、一切都运行得很好:

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);

这将产生正确的结果为 0xA4(请注意,我的多项式为 0x31)。

当我尝试使用 VCRC 执行相同操作时、得到的结果为 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);

有什么想法我做错了?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Trey、

    我无法找到您的实施存在任何明显错误。

    值得怀疑的一个方面是数据缓冲区和 MSB-LSB 排序、但即使这看起来也可以。 C 语言的实现依赖于__byte 内在函数、并使用奇偶校验来索引到数组中、因此计算顺序(我期望)为 0x00 0x01 0x02 0x03 0x04 0x05 0x06。 同样、在 VCRC 情况下、计算顺序是首先是 LSB、然后是 MSB、因此 0x00 0x01 0x02 0x03 0x04 0x05 0x06。

    只是绝对地将这排除为可能的问题 — 也许尝试交换 VCRC 计算的字节顺序、看看会发生什么情况。

    此外、您提到 0xA4 是正确的结果 — 您能告诉我您使用的在线计算器工具来得出这个结论(以及您的数据集和 CRC 的相应设置)吗?

    谢谢、

    Sira