• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 46 subscribers
  • Views 396 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Problem with 0xffffff

Samuel WuMingXian
Prodigy 20 points
Part Number: ADS1255

 

Hi,

 

We use the ADS1255 and test Vin= 1V and with single channel read 10 data continuously.

SYNC operation is provided via the SPI command.

But we have an issue that we read 0XFFFFFF once around every 20~30 times.

We follow the sequence for Single channel read continuous.

We found that when read 0XFFFFFF and we resend RDATAC command, sometimes the issue can be fixed but sometimes cannot.

Have you ever been before or do you have any comments?

Thank you.

  • 0
    TI__Mastermind 44550 points
    Hi Ming,

    Welcome to the TI E2E Forums!

    In your "Single channel read continuous" sequence, do you ever exit the RDATAC mode, by sending the "SDATAC" command or any command other than "0x00"?

    I could see the device failing to return the correct data if somehow you exited the RDATAC mode. In this case, you would need to send the RDATA command to retrieve the data. As a sanity check, you might want to try reading data in SDATAC mode and always sending "RDATA" when clocking out the data.

    The other possibility is that the device may not be responding to your command at all (hence DOUT may remain high, or low). In this case, is it possible that the /RESET, /PWDN, or /CS pins are not set correctly or that another device on the same SPI bus is causing a contention? ...Those would seem to be the most common reasons the device might not respond. An SPI timing issue might also be possibility, but usually with a timing issue you would still see some response from the device.

    Best regards,
    Chris