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.

ADS1255 randomly spurious data readout errors

Other Parts Discussed in Thread: ADS1255

Hello TI-Team,

We are using the ADS1255 in RDATAC mode.

Setup and ReadOut works as expected.

But sometimes we get data readout errors.

The clock frequency is driven by an oscillator of 8MHz (datasheet 0.1 -> 10MHz)

The SPI-readout clock is 2MHz (maximum -> t1 SCLK period >= 4 * tclkin).

The converting speed is set to 500 SPS.

SPI is read by an ATMEL ATmega 2561.

CPU runs with 16MHz.

We use the /DRDY signal to enter an interrupt routine.

Then we set /CS low (active) and read three bytes via SPI.

Before unasserting /CS, there is a wait time (t10) of 2µs.

But sometimes it fails and the data is corrupted and leads to spikes.

Further investigation shows the following:

Second Byte read has the same value as the first one.

After reading byte three, /DRDY remains low!

This makes it possible to trigger this event.

In case of this event we read a fourth byte via SPI and the /DRDY goes high.

If we inject some NOPs (i.e. 125ns) waiting time before asserting /CS in the interrupt routine, we get less errors.

If we inject 1µs we will get more errors again.

From the data sheet I would expect that 1µs wait time between the last byte read to the unassertion of the /CS would be sufficient, but then we get more errors too.

When we reduce the SPI-clock to 1MHz there are no errors, but it doubles the readout time.

In the future we need more than one channel to read and higher sample rates, so the readout time counts.

The timing seems really tricky. How can we use the 2MHz SPI read-out without errors?


regards

Jens Zilian

P.S.: scope screenshots are available if neccessary

  • Hi Jens,

    Welcome to the TI E2E forums! That would be helpful if you could share the scope-shots!

     

    What is the state of the DIN pin during data readback, is it held low?

    1. The behavior you described makes it seem like the device is responding to an RDATA command, which would repeat the first data byte, and take 4 bytes for /DRDY to return high.
       
    2. Otherwise, it may be that the first command byte is not being recognized by the device and the 4th byte appears to the ADS1255 as the last byte (which would probably make it a coincidence that the first and second data bytes match). Are the 1st and 2nd data bytes non-zero when they match?

     

    ...You might try adding a short delay (>50 ns) between /CS low and your first SCLK rising edge. Adding a short delay here can often times fix issues where the first command byte is not recognized or decoded properly. Even though the t3 time allows for 0 ns between /CS low and the first SCLK rising edge, phase delays could make the SCLK rising edge actually occur before /CS goes high; therefore, it is good practice to include a small delay time here...When you slow down the SCLK frequency to 1 MHz, you might be providing a bit more time between these edges and alleviating the issue.

     

    Best Regards,
    Chris