• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 464 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.

TMS320F28388D: CRC library on C2000, issue with CRC8 calculation

Anthony Tran
Prodigy 20 points
Part Number: TMS320F28388D

Hi, 

I've been testing the CRC library with the following setup:

uint8_t 
uint16_t buffer[2] = {0x00FF, 0xABCD};

CRC.seedValue = INIT_CRC8;
CRC.nMsgBytes = 4;
CRC.parity = CRC_parity_even;
CRC.crcResult = 0;
CRC.pMsgBuffer = (uint16_t *)buffer;
CRC.pCrcTable = (uint16_t *)&crc8Table[0];
CRC.init = (void (*)(void *))CRC_init8Bit;
CRC.run = (void (*)(void *))CRC_run8Bit; // Using VCU

// Initialize the handle
handleCRC = &CRC;

// Run the 8-bit table look-up CRC routine and save the result
CRC.init(handleCRC);
CRC.run(handleCRC);
crcResultC = CRC.crcResult;

Expected result: 0xC9

Actual result: 0x8D

I understand that with CRC_parity_even, CRC starts at the low byte of the first word. This means the actual input data is in this order: 0xFF, 0x00, 0xCD, 0xAB. With that, the result of 0x8D is explainable.

So I thought I could fix it by changing the parity to CRC_parity_odd.

However, the result is: 0x1B

I have tried another way, which is still using CRC_parity_even, but I needed to swap the bytes in each word before feeding into the CRC calculation. The result then becomes 0xC9 as expected. But I believe it's not ideal.

Could you let me know what is the issue with my code?

Thanks

Anthony

  • 0
    TI__Mastermind 25930 points

    Anthony,

    Yes, your observation is as expected.

    When you change parity to ODD, all it does is start the calculation from the odd byte i.e. it skips the even byte of the first word. This is why that approach didn't work.

    The reason why you had to flip the bytes prior to the compute is because the CRC library is implemented such that it computes the CRC on the low byte of the word, followed by the high byte, and so on. However, what you want is the opposite.

    We actually have a solution for this implemented in the VCU0 library (refer to the c28x_vcu0_library project,vcu0_crc_32_hilo_order_swap.asm). So this is currently implemented only for the VCU0 CRC32. But the solution can be extended to the VCRC library CRC8 (which is what you would be using in F2838x).

    Thanks,

    Sira