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.

MSP430F6659: Need help with CRC-16 calculation acc. to CCITT to communicate via TMS3705 to TMS37157

Part Number: MSP430F6659
Other Parts Discussed in Thread: TMS3705, TMS37157,

Hello,

I'd like to calculate the CRC-16 acc. to CCITT to communicate via TMS3705 to TMS37157.

I have a working code just using shift operation.

I adopted this: https://en.wikipedia.org/wiki/Computation_of_cyclic_redundancy_checks, code fragment 5, shift register based division, LSB first and it works perfect.

The MSP430F6659 has a hardware CRC module and I'd like to use this, because it is the faster and more elegant solution.

This is the code I tested so far, but it didn't deliver the correct result in comparison to the software solution:

  unsigned int i, CRC_Result, CRC_Init = 0x3791;
  
  CRCRESR = CRC_Init;  // CRCINIRES = CRC_Init;
  for(i=0; i<length; i++)
  {
    CRCDIRB = string[i];
  }
  CRC_Result = CRCRESR;

  return(CRC_Result);

I try to use the reverse (see above) and the non reverse registers, but non of the version seem to work.

Please help

Kind regards

Gerd

  • I do not see any "actual" initialization on the CRCINIRES register (your code comments that out)!
    Are you doing that somewhere else in the code?
  • Hi Mike,

    I played around with (I hope) all possible combinations of MSP430 registers, but none gave back the correct CRC16.

    At the moment, I'm using a software CRC16 calculation and it works perfect. I can see that the TMS37157 accepts the CRC16.

    This is the software CRC16 code:


    unsigned int funcTMS3705_SW_CRC16(unsigned char* string, unsigned char length) { unsigned int i, j, crc = 0x3791; for( i=0; i<length; i++) { crc = crc ^ string[i]; for( j=0; j<8; j++) // Assuming 8 bits per byte { if( crc & 0x0001) crc = (crc >> 1) ^ 0x8408; // if rightmost (most significant) bit is set else crc = crc >> 1; } } return(crc); }

    But this is not how it should be.

    This is my current version of the hardware CRC16:

    unsigned int funcTMS3705_CRC16(unsigned char* string, unsigned char length)
    {
      unsigned int i;
      
      CRCINIRES = 0x3791;       // Init CRC Initialization and Result Register CRCINIRES with 0x3791
      
      for(i=0; i<length; i++)   // Loop
      {
        CRCDIRB = string[i];    // Input data in CRC Data In Reverse Register CRCDIRB
      }
      
      return(CRCRESR);          // Return data from CRC Reverse Result Register CRCRESR
     }
    

    As I said before, I played around with all the registers and non of the combinations did a good job.

    I hope you are able to find a solution.

    Kind regards

    Gerd

  • Hi Gerd,

    it seems to me that your c-code sample calculates a CRC-XMODEM (Polynom: 0x8408), while the Hardware CRC module of the MSP430F5xx family calculates a CRC-CCITT (Polynom: 0x1021). That both CRCs don't match is intention :-)


    Regards
    Christoph
  • Hi Christoph,

    Now I'm completely confused. ;-)

    On page 39 of the TMS37157 datasheet it clearly says:
     
    A Cyclic Redundancy Check (CRC) generator is used in the TMS37157 during receipt and transmission of data
    to generate a 16-Bit Block Check Character (BCC), applying the CRC-CCITT algorithm
     
    My software version definitely generates the correct CRC16. Otherwise the TMS37157 would not respond positive.

    As I said in my original post, I found the software version in Wikipedia and it works perfect for the TMS37157.

    How ever, is there a chance to do the same with the MSP430F6659 hardware CRC engine?

    By-the-way, the polynom: 0x8408 is just the reverse of the polynom: 0x1021

    Kind regards
    Gerd

  • Hi Gerd,

    you are right, CRC-CCITT has often confused me too:-) 

    But I think srecord does CRC-CCITT the right way:

    <srecord.sourceforge.net/crc16-ccitt.html

    And Lammert Bies does an excellent job in describing the different CRC-CCITT "flavors"

    www.lammertbies.nl/.../crc-calculation.html>

    With this information in mind I think it should be possible to find out if the CRC algorithm of TMS37157 reverses the data/CRC and/or if the result requires performing a one's complement.

    hope this helps

    Christoph

  • Hi Christoph,

    Thanks a lot for these background information.

    Now I know much more about CRC16-CCITT.

    But, sorry to say, this was not my original question.

    I asked for help how to implement the correct CRC16-CCITT using the MSP430F6659 hardware CRC module.

    Can you help?

    Kind regards

    Gerd

  • Hi,

    This is still not solved.

    Any ideas?

    Kind regards

  • As I can see from your source code, you are calculating CRC byte (character 8-bits from string) value.

    I am using 5xx CRC hardware module with normal and reverse bit order. Before calculation, CRCINIRES is set to 0xFFFF. During calculation, each word (16-bit) is written to CRCDI or CRCDIRB (depending on bit order). At the end, result is in CRCINIRES. Value calculated by micro is compared with value calculated on PC side. 

    
    D:\msp430>flash -f test_msp430f5510.txt -e -ws -crc -crcr
    
    File: "test_msp430f5510.txt"
    Address: 08000  Words: 16384
    Size: 32768 bytes
    
    Found SBW+ at COM4
    
    Get Device
    # JTID Fuse Device Core Hard Soft LotWafer DieX DieY
    0  91   OK   3180  1104  12   12  013BB046 2A00 2100
    1  91   OK   3080  1104  30   10  B15B9446 2000 1700
    2  91   OK   3180  1104  12   12  013BB046 1200 1E00
    3  91   OK   3881  1106  10   10  219CA446 1800 0F00
    
    Erase
    
    Write Smart
    Time: 208 ms  Speed: 153,8 KB/s
    
    CRC
    File  #0   #1   #2   #3
    23B1 23B1 23B1 23B1 23B1
    Time: 33 ms  Speed: 942,9 KB/s
    
    CRC Reverse
    File  #0   #1   #2   #3
    C841 C841 C841 C841 C841
    Time: 34 ms  Speed: 937,9 KB/s
    
    Release Device
    
    Total Time: 406 ms
    
    D:\msp430>
    

**Attention** This is a public forum