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: abnormal readout value in continue mode

Part Number: ADS1255

Tool/software:

Hi team,

There is a problem of using ADS1255 adc in continue mode reading.

The fclk for ADS1255 is 8MHz and operating in 30Ksps continue mode.

The SPI read out program refering DRDY signal falling edge to read out the 3 bytes data.

However, the readout will randomly wrong in our testing. 

The master SPI is tiva SSI driver code and we also measured the SPI waveform and it looks like ok.

Below diagram is the wrong reading we captured.

The typical error read out looks like the MSB byte duplicated of the reading and casued the 24 bits (3 bytes ) data wrong.

ex: AA BB XX are the neighboring values.

The abnoraml one might like AA AA BB. 

Another wrong case is the Middle byte duplicated like AA BB BB.

We have some tried but the error still randomly happen.

1. reduce to 15K sps

2. adjust SPI clock rate (2MHz ~ 1.6MHz)

We think the SPI read timing is no differnet in correct / wrong case and should meet ADS1255 spec.

We think the fclk 8MHz and the operating setting 30Ksps should still meet the specification.

What might be the problem and any suggetion of this?

Regards,

Paul

  • Hi Paul Chou,

    What it looks like you are seeing in that "bad" frame is that the data is being reset mid-frame. That is why you see 0x01h twice in a row, like you start clocking out data, then the frame gets interrupted, then you start clocking out the same data again. So you only see the first two bytes of data, and the ADC interprets this as only 16 bits of the total 24 bits of data got clocked out. Since the frame didn't finish, the DRDY behavior is different.

    Have you checked the SPI communication signals on a scope to make sure they are clean, and that you are getting nice sharp edges on the clock signals? And that there are no disturbances? Check on both the ADC and controller side, because it seems like the ADC is sensing something that is causing the read back to restart mid frame

    -Bryan

  • Hi Bryan,

    Thanks for the reply and suggestion.

    I've used the scope to measure the SPI communiction and looks the signal is fine.

    According to the "bad" frame data is randomly happend so I cannot capture them from scope.

    Another reason I think the signal quality may fine is that the previous post of Logical/protocal analyzer screenshot.

    The log data is identical to the data what I read from software side.

    That means the protocal analyzer can idenitfy the same value as what the MCU read from SPI.

    From the data sheet,  it's only sending SLCKs to shift out 24 bits data in DRDY lower period in continuous mode.

    Is that means we can sending the 24 SLCK any time just make sure it locate in the DRDY low period?

    Any other requirement?

    Thanks,

    Paul

  • Hi Paul Chou,

    As mentioned, it looks like you are seeing the data readback frame reset in the middle of your actual 24-bit frame, hence the repeated data. You can also see that the DRDY behavior is different in the third frame compared to the first two. DRDY is a small pulse in the third frame, which indicates that the data was not retrieved i.e. you did not read out all 24 bits.

    This would suggest there is something resetting the frame, maybe a transient that is not visible on the logic analyzer but would be visible using the scope. It would be helpful to see this behavior when the fault occurs

    Also, the time you take to drop CS low after DRDY drops low is changing, see the plot below where the first two instances are pretty similar, while the third instance is much larger (circled in blue). Is your processor running other tasks in the background that is causing this delay? I would expect the behavior to be very consistent from one conversion to the next

    -Bryan