• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 46 subscribers
  • Views 400 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

ADS1256 Conversion Sequence (waking up with write to MUX reg?)

Fabiola De la Cueva
Prodigy 10 points
Other Parts Discussed in Thread: ADS1256

Hi all,

I have been asked to review a board that uses the ADS1256, and I don't understand how it can even be working. The ADC runs on with an 8MHz clock, the ADC registers are not changed from their defaults, and their conversion sequence goes like this:

Send STANDBY command and wait.  When it's time to do a conversion:

Send 0x51, 0x00, 0x28 (Configure MUX register so Vin = AIN2-AINCOM)

...wait for DRDY to go low...

Send 0x01 and read out 3 bytes (the conversion result)

*** while reading the middle byte of the conversion result, DRDY goes high for about 4 SPI clock cycles in the middle of the byte, then goes back low ***

Send STANDBY command and again wait until it's time to do another conversion.

So, my questions:

1. It appears the ADC is waking up from standby by writing to the MUX register.  I thought the proper way to wake it up was using the WAKEUP command, so why does this work and are there any side effects of doing this?

2. I really don't like the DRDY line going high while reading the conversion result -- doesn't this mean the ADC is updating the conversion result?  Specially puzzling is the fact it only goes up for about 3us, then goes low again until it finishes shifting out the 3 bytes, so this is too fast the for ADC to perform another conversion during the short pulse.

So, before I suggest they need to completely change their conversion sequence to comply with the datasheet recommendation, is there something I missed in the datasheet where this sequence would yield valid data? (we are getting what appears to be valid data)

Thanks!

Fabiola

  • 0
    TI__Mastermind 44680 points

    Hi Fabiola,

    I'm sorry for my delayed response.

    1. I agree that the order of operations is sketchy. A WAKEUP command is the proper way to exit standby mode, but it is possible to interrupt standby mode with SCLK activity while the /CS pin is low.

    2. I don't like either! It sounds like /DRDY is performing an update pulse (refer to Figure 4 on page 7 of the data sheet). If a data read operation has not completed, /DRDY will stay low until the next conversion completes and data is getting written to the output buffer. It is possilbe that data read is able to sqeak out the last bits of data before the output buffer is updated, but then again, you don't know if the last bits comming out correspond to the lastest conversion result.

      You definietely want to see the read operation complete before this happens. It is odd for this to be an issue when the /DRDY pin is being monitored, unless the processor is reacting slowly to the /DRDY falling edge or if the SCLK speed is slow and data read back is taking too long. If a fast sampling rate is causing too tight of a timing requirement, then you may need to recommend using the data "read by command" method, which will not produce corrupted data when conversion results update during the read operation.

    Best Regards,
    Chris