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.

ADS124S08: CRC trouble

Part Number: ADS124S08


Hello, TI

I have an ADS124S08 that I'm working to implement into a larger project. I have a few things I want to measure with it, but for now, I'm playing with measuring an RTD. I'm getting what I think are good readings, but the CRC doesn't line  up with what I'm getting. 

I'll use a reading I got yesterday as an example. When measuring a 100-ohm resistor, the reading 0x32,0x33,0xaa,0x62. The first three is about what I expected, but when I tried doing CRC on that value, I got 0xAE as a checksum value, not 0x62. I put the calculation I did at the bottom of this post in full, but basically, I

concatenated the first three bytes, and left shifted them by 8, adding trailing zeros. 

lined up the divisor indicated in the ADS124S08 documentation, 100000111, with the most significant 1 in the data. 

Xor'd the data with the divisor. 

Moved the divisor to the next most sigificant 1 bit, and repeated until the data was less than 100000000. 

I'm assuming that the chip is Sending the CRC correctly, and I'm doing the algorithm wrong, but I can't seem to find my mistake. And I don't think it's an arithmetic error, this happened on multiple readings, so I must be doing something systematically wrong. 

If anyone can help me understand this algorithm, I would greatly appreciate it. 

Original reading (left-shifted by 8) 0 0 1 1 0 0 1 0 0 0 1 1 0 0 1 1 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0
divisor 1 0 0 0 0 0 1 1 1            
remainder 1 0 0 1 0 1 1 0 1 0 0 1 1 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0
divisor 1 0 0 0 0 0 1 1 1          
remainder 0 0 0 1 0 1 0 1 0 0 0 1 1 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0
divisor   1 0 0 0 0 0 1 1 1          
remainder   0 0 1 0 1 0 1 1 0 1 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0
divisor     1 0 0 0 0 0 1 1 1        
remainder     0 0 1 0 1 1 1 0 0 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0
divisor     1 0 0 0 0 0 1 1 1        
remainder     0 0 1 1 1 0 1 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0
divisor       1 0 0 0 0 0 1 1 1      
remainder       0 1 1 0 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0 0
divisor       1 0 0 0 0 0 1 1 1      
remainder       0 1 0 1 1 1 0 1 1 1 0 0 0 0 0 0 0 0 0
divisor       1 0 0 0 0 0 1 1 1      
remainder       0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0
divisor         1 0 0 0 0 0 1 1 1    
remainder         0 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0
divisor         1 0 0 0 0 0 1 1 1    
remainder         0 1 0 0 0 1 0 0 1 0 0 0 0 0 0
divisor         1 0 0 0 0 0 1 1 1    
remainder         0 0 0 0 1 0 1 0 1 0 0 0 0 0
divisor           1 0 0 0 0 0 1 1 1  
remainder           0 0 1 0 1 0 1 1 1 0
Remainder is now smaller than the divisor, so the CRC is 01011110, or 0xAE.               
  • Hi Cassius Peter,

    It does appear that the long division method you are using is correct.  There is also a CRC Excel based calculator inside the ADS1x4s0x Calculator Tool that is on the web landing page.  And there is also an application note on CRC available.

    One consideration is the CRC is calculated on the complete data transfer.  This means if the STATUS byte is also enabled, you must also include this byte as well in the calculation. Also, to eliminate any software issues I would recommend that you capture the data transfer with a logic analyzer or oscilloscope and compare that data with your software data.  If you send me shots of the communication I can help you troubleshoot further.

    Best regards,

    Bob B

  • Hello, Bob. 

    I briefly considered that, but I am not sending a status bit. Here are my register settings, mostly stolen from TI's official program. 

    Register 2: 0x24;
    Register 5: 0x06;
    Register 3: 0x0A;
    Register 6: 0x07;
    Register 4: 0x14;
    Register 9: 0x12; <- if my understanding is correct, if I wanted to enable the status bit, I would set this to 0x13. 
    Register 7: 0xF5;

    I'll work on getting a screenshot from my oscilloscope. Hang tight for a bit.

  • Actually, I don't even need a screenshot. I realized what I was doing wrong. 

    Currently, I'm reading via the RDATA command. The code specifies that you ignore whatever's coming in at the same time you send an RDATA command out, and then take the next three to five, depending on whether you're sending the status and CRC bytes. I thought I was filtering out that first byte, but I wasn't, so I was inadvertantly ignoring the last byte. Now that I've corrected it, the CRC is matching up every time. 

    Thanks for your assistance, looking at the waveform for you is how I realized I was getting more bytes than I expected.