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.

ADS1263: Bad readings after retrying Read Data command

Part Number: ADS1263

Hello,

I'm using the ADS1263 ADC1 on continuous mode with CRC enabled.

Whenever I get a DRDY interrupt I send the RDATA1 command on SPI to read the conversion data.

Whenever the CRC is correct, I get good readings.

However, when the CRC is bad, I immediately retry the RDATA1 command a few times. The issue is that whenever I do this, a following attempt passes the CRC check, but the reading is way off (testing with a fixed voltage).

From what I read in the documentation, re-issuing RDATA commands should return the previous reading value with a 0 status bit (my status byte is disabled anyways).

Would anybody have an idea of what the issue is? Thanks in advance.

  • Hi l r,

    Can you explain what you mean by "when the CRC is bad"? Are you getting random data errors that cause the CRC reading (from the ADC I presume) to be bad? Or are you somehow intentionally corrupting the data?

    Can you provide logic analyzer plots showing the CRC error and your multiple read attempts? Please include CS, SCLK, DIN, DOUT, and DRDY in the plots so we can review what you are seeing

    -Bryan

  • Hi Bryan,

    Thank you for your response.

    What I mean is I get invalid CRCs, likely due to random bit errors on the SPI bus. I get approximately 1% of frames with a CRC error.

    When this happens I retry sending the RDATA command, and what usually follows is a frame with a valid CRC but a bad reading.

    I've just noticed the bad readings have some patterns: I'm expecting a value around 0x46xxxxxx, and what I get is usually either 0x23xxxxxx or 0x046xxxxx, however I also got 0x12xxxxxx once.

    Another relevant finding I just discovered: the ADS on my board shares the SPI bus with 2 other slaves on different SPI modes, and I only get those bad readings when the other slaves are also active.

    I would think it could be an SPI issue, but all the bad readings have a valid CRC, which leads me to think there's something wrong on the ADS side. I don't have a setup to use a logic analyzer today, but I can do it next week.

  • It turns out the issue was a bug on the switching of SPI modes between slaves in the master's program...

    And that coupled with the CRC property of CRC8(x >> 1) = 0x80 | CRC8(x) made me think the ADS was calculating the CRC of bad data.

    Sorry for the noise.