• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 590 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.

Tformat crc calculation read by SCI

user805897
Prodigy 210 points
Other Parts Discussed in Thread: TMS320F280049C

When I read the Tformat encoder using SCI, I made the CRC calculation as follows. The code before __flip() of the bit string was difficult to understand, and I thought that __flip() would not be necessary when reading from SCI, so I made it. If I have missed something, please let me know.

#include "device.h"
#include "driverlib.h"
void SCI_tformat_generateCRCTable(uint16_t *pTable)
{
uint16_t i, j;
uint16_t accum;

uint16_t polynomial = 0x0081;

for(i = 0; i < 256 ; i++)
{
accum = i;
for( j = 0; j < 8; j++)
{
if(accum & 0x0001)
{
accum = ((accum >> 1) & 0xFF) ^ polynomial;
}
else
{

accum = ((accum >> 1) & 0xFF);
}
}
pTable[i] = accum;
}
}


uint16_t SCI_tformat_getCRC( uint16_t * msg, uint16_t *crcTable, uint16_t rxLen)
{
uint16_t i;
uint16_t accum = 0;
int *pdata;
pdata = (int *)msg;
for (i = 0; i < rxLen; i++) {
accum = crcTable[(accum ^ __byte(pdata,i)) & 0xFF] ^ (accum >> 8);
}
return accum;
}

  • 0
    Prodigy 210 points

    When I pasted the text, all the tabs were gone and it was hard to see, so I pasted an image.

  • 0 in reply to user805897
    Prodigy 210 points

    processor type TMS320f280049C

  • 0 in reply to user805897
    TI__Mastermind 32655 points

    Hi,

    Can you please provide details on the issue you are facing? Also, were you using any reference code from TI?

    Regards,

    Veena

  • 0 in reply to Veena Kamath
    Prodigy 210 points

    In PM_tformat_getCRC of PM_tformat_crc.c file, there is the following statement, which I do not understand why it is necessary. I would like to know if the specific 2 bytes need to be processed differently even for data from SCI where the bit sequence is not inverted this time.

    //
    // Do the first two bytes, special case
    //
    i = crcAccum ^ (__byte(pdata, index--));
    crcAccum = crcTable[i] ^ crcAccumLow;
    i = crcAccum ^ (__byte(pdata, index--));
    crcAccum = crcTable[i];

    Translated with www.DeepL.com/Translator (free version)

  • 0 in reply to user805897
    TI__Mastermind 32655 points

    Hi,

    I will check with the module owner and get back to you

    Regards,

    Veena

  • 0 in reply to user805897
    TI__Guru* 92780 points

    Hello - is the code provided not working ?  I don't recall the specifics of the implementation - however it was tested with an actual encoder responding to the commands. 

  • 0 in reply to Lori Heustess
    Prodigy 210 points

    Thank you or your replay.

    This is the CRC when SCI is used for Tformat instead of SPI, since SCI does not invert the bit sequence like as SPI does.
    I don't understand why the first 2 bytes are special case when using SPI. Is this the case with SCI also a special case?

  • 0 in reply to user805897
    TI__Guru* 92780 points

    The CRC routine provided is very generic and will work with different lengths of data.  Since the T-Format data is always a multiple of 8, it can be simplified.  I'm not sure the bit of code you mention is even used for T-Format.  My suggestion is to step through the code with SPI data to get a feel for what data it is using and what code is being executed and which is skipped.  Then apply the same to your own application.

  • 0 in reply to Lori Heustess
    Prodigy 210 points

    Hello, thank you for your reply.
    Since the current hardware is connected to SCI, I created this code exclusively for SCI to read the CRC.
    What I want to know is that I don't understand why your SPI code treats the first 2 bytes specially. I am not asking if my code works or not. I just don't understand why the first two bytes are a special case.
    Please tell me why the first two bytes are a special case.

  • 0 in reply to user805897
    TI__Guru* 92780 points

    Unfortunately I don't recall the specifics - this code was written a long time ago. From the code, it seems to only a special case if crcAccum is set to something different in the previous if-then code.  For T-format, I believe crcAccum will always be 0xFF since the number of bits is always a multiple of 8.  I would have to step through the code to see if I am correct.  There are a lot of CRC algorithms and code examples out on the web. 

  • +1 in reply to Lori Heustess
    Prodigy 210 points

    Thank you for your answer.
    For a long time I did not understand how this special case could happen. This time, it is 8 bits and there is no bit inversion, so I think that the special case will not occur.
    If the calculation does not match, there must be some kind of bug, or if not, it must be a hardware problem.