• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 652 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28379D: VCU II CRC computation endianness

Quentin Gaspart
Prodigy 60 points
Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Hello, 

I am currently using the VCU library and develop some basic uses of VCU to compute CRC. 

My company Watt &Well, want to use the VCU to calculate the CRC of packets exchanged between two TMSF2837x devices.

As I said my code use the VCU library and is inspired by the ccs example of C2000ware available at C2000Ware_2_00_00_03\libraries\dsp\VCU\c28\examples\crc\2837x_vcu2_crc_16

I tried to reproduce the CRC computation of the reference ASCII string 123456789 or in hexa 0x313233343536373839

Here are the different steps

I declare two array with both endianness 

static const uint16_t testInput1[5] = {0x3231, 0x3433, 0x3635, 0x3837, 0x0039}; 
static const uint16_t testInput2[5] = {0x3132, 0x3334, 0x3536, 0x3738, 0x3900}

Here find the initialization of CRC structure and the computation of the CRC

CRC.seedValue = INIT_CRC16;
CRC.nMsgBytes = 9;
CRC.parity = CRC_parity_even;
CRC.crcResult = 0;
CRC.pMsgBuffer = (uint16_t *)&testInput1[0];
CRC.pCrcTable = (uint16_t *)&crc16P2Table[0];
CRC.init = (void (*)(void *))CRC_init16Bit;
CRC.run = (void (*)(void *))CRC_run16BitTableLookupC;

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

// Step 4: Run the 16-bit table look-up CRC routine and save the first result
CRC.init(handleCRC);
CRC.run(handleCRC);
crcResultC_1 = CRC.crcResult;


CRC.crcResult = 0;
CRC.parity = CRC_parity_odd;
CRC.pMsgBuffer = (uint16_t *)&testInput2[0];
CRC.run(handleCRC);
crcResultC_2 = CRC.crcResult;

crcResultC_1 is equal to 0x31C3 (calculated in CRC_parity_even and is the expected value)

crcResultC_2 is equal to 0x142E (calculated in CRC_parity_odd and is not the expected value)

I expected that both CRC are equal but are not.

I use the following website to have the right answer.

https://crccalc.com/          

check CRC-16/XMODEM row for the corresponding CRC computation.

Could you explain me the reason of this difference?

Best regards,

Quentin Gaspart

Firmware engineer

  • 0
    TI__Mastermind 25930 points

    Quentin,

    I believe this is occurring because in the odd parity case, the bytes used for CRC computation begin with the MSB of the word i.e. your testinput2[] is 0x3132, 0x3334, 0x3536, 0x3738, 0x3900, but the bytes used for CRC computation will not include 0x32, and since the numbytes = 9, it will include the last 0x00.

    If you wanted a match for your first result, and you wanted to use odd parity, I think your test input would have to be:

    0x3100, 0x3332, 0x3534, 0x3736, 0x3938

    Can you please check if this works as I expect?

    Thanks,

    Sira

  • 0 in reply to Sira Rao80
    Prodigy 60 points

    Sira,

    It is indeed working even though I did not get the logic of where is placed '00'.

    Best regards,

    Quentin

  • 0 in reply to Quentin Gaspart
    TI__Mastermind 25930 points

    Quentin,

    Good to know that it is working.

    Remember that the format in memory will be little-endian, with the LSB in the lower address and the MSB in the higher address. So with your testInput1[], you can visualize it as:

    lowest address: 0x31

    next address: 0x32

    ...

    address:    0x39

    ...highest address: 0x00

    With "even" parity, the CRC calculation will begin at the LSB of the 1st specified word in memory. Thus, the 9 bytes used for calculation will be 0x31, 0x32, ..0x39.

    Now the next case.

    If you define the testinput the way I suggested i.e. 0x3100, 0x3332, 0x3534, 0x3736, 0x3938, then the format in memory is STILL little-endian, so you can visualize it as:

    lowest address: 0x00

    next address: 0x31

    ...

    address:    0x38

    ...highest address: 0x39

    NOW, we select "Odd" parity, so the CRC calculation will begin at the MSB of the 1st specified word in memory. Thus, the 9 bytes used for CRC calculation will be 0x31, 0x32, ..0x39. This will lead to the same CRC as before.

    On the other hand, if we used your testInput2 0x3132, 0x3334, 0x3536, 0x3738, 0x3900, with "Odd" parity, the the 9 bytes used for CRC calculation will be 0x31, 0x34, 0x33, 0x36, 0x35, 0x38, 0x37, 0x00, 0x39

    Does this make sense?

    Thanks,

    Sira