• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 45 subscribers
  • Views 512 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.

ADS124S08: Issue with reading conversion data

David Kidwell
Prodigy 10 points
Part Number: ADS124S08

I am interfacing an ADS124S08 (currently using your evaluation board but with runs cut - basically a simple power supply and holder for the chip) to a FT240X (A parallel USB interface).  I am using bit-banging on the FT240X to communicate with the ADS124.  I am running the FT240X and bit banging using a LabView interface.  I can successfully communicate, read registers, change registers, and sometimes read A/D conversions.

I am using conversion on demand (reg 4 is set to X22 - single shot, Sinc filter, 10 SPS).  Problem occurs no matter what setting on these registers.

The problem is very unusual.

I am reading the conversions in a direct mode after issuing a start convert command with single-shot (as mentioned above).

After reading the 18 registers, I issue a start command and then wait for the /READY to go low.  Immediately after the start command, the /READY goes low and I read garbage.  If I repeat this command, it reads OK no matter how many reads I use.  Reading the registers continues this sequence where the first start-read is garbage.

Now, that is reading AD1 (reg 2 is set to 1C ).  If I ONLY change reg 2 to a x2C value (reading AD2) and issue a START command, it reads correctly.  Then if I continue the start-read, it reads garbage.  However, if I insert a NOP before the start-read, it reads correctly.  If I continue the sequence NOP-Start-read -NOP-Start-read everything is OK.  Using a scope, the NOP reads the first byte of the previous conversion (as it should).

Now if I switch to another register, sometimes I need NOPs sometimes I do not.  If I use too many NIOPs, then it reads garbage.

Basically, the /READY line is going low immediately upon issuing a START command when the system is not working but behaving correctly (delaying ready until conversion is complete) when the system is working.  I can delay the going ready by changing the number of SPS or low-latency filter vs. Sinc so I believe that the system is at least responding correctly.  I also read the registers and any changes are correct.

I have tried for DAYS to toggle other lines programmatically - such as CS (currently tied low) and /RESET (currently floating) and START (currently tied low).  Thinking it was a programming error.  Years ago, I worked with the TIMSP430F149 and also spent days on finding a silicon error.  No errata was reported for this chip so I assumed that I must be making a stupid programming error.

Many variations on the program for troubleshooting, without success and monitoring lines with a scope and waveforms look great.  Even tried changing data rates.  Tried stopping conversion, wakeup, etc, without success.

NOTE: /READY refers to the DOUT/\RDY line but the /DRDY line behaves the same (mirrored on the scope).

Any thoughts would be appreciated on this unusual behavior.

  • 0
    TI__Guru** 112705 points

    Hi David,

    Welcome to the E2E forum!  The very first thing to do is tie the RESET pin high as there is no internal pullup on the ADS124S08. Leaving the pin in a float state could inadvertently cause a reset condition to take place.

    The second consideration is the usage of DOUT/DRDY.  The pin will transition from high to low when the conversion completes.  However, the transition period is quite short, so usually an interrupt driven method is used as opposed to a pin polling method.  If a polling method is required, then the output pin should be forced high as the last bit from a conversion result could either be high or low making polling difficult.  If you take a look at Figure 6 in the ADS124S08 datasheet you will see that DOUT/DRDY will transition similar to DRDY, but the first SCLK will force DRDY high whereas DOUT/DRDY will transition relative to the contents of the output shift register.  The data in the output buffer is in a ring buffer.

    I can't totally follow what you are saying so some scope or logic analyzer shots would be helpful.  If you are using the 10sps rate with the sinc3 filter, it should take roughly 300ms after the START command is issued before DOUT/DRDY goes low.  Make sure that you are not misinterpreting the actions of the last bit transmitted as the response for DRDY going low. 

    For example, if after you configure the ADS124S08 as desired and you issue the START command (and assuming no register reads have taken place following the initial power up) you may not see DOUT/DRDY go high.  The initial state of the ADC will be '0' in the output buffer when reading direct and there will be nothing to drive the state of the DOUT/DRDY pin high.  At this point if you poll the pin, the pin will be '0' which would appear as though the conversion has completed even though it has just started.

    If you want to poll the pin searching for a change from high to low, you need to force the DOUT/DRDY output high.  You can do this by reading a register where the last bit in the register is high.  Possible examples would be register 0x06 where the IDAC magnitude selection is turned off, or register 7 where the IDACMUX for IDAC1 is disconnected.  Depending on the desired configuration there may be some other registers that could be used as well.

    So the best method for polling DOUT/DRDY is to:

    • send the START command
    • immediately thereafter read a single register where the last bit is high
    • then poll the DOUT/DRDY for a high to low transition

    Other potential options would be to:

    • use a timer and wait for the conversion to complete and then read the data
    • Poll DRDY instead of DOUT/DRDY
    • use the RDATA command to read the last conversion completed instead of reading data direct

    Best regards,

    Bob B

  • 0
    Prodigy 10 points

    THANK You!  This was exactly the issue and it caused the bizarre behavior on this system.  I fixed it using your suggestion to read a register with the appropriate bits set to set the DOUT/RDY line.  What was happening with the NOPs is it would read a previous ADC result and if that line that I am polling gets set, then the system would work.  Certain ADCs had the just right values to always set this line but others did not.

    No where in the manual is it described that this line is more of an interrupt line.  Even in that case, it should be set high upon a Start request.  This is just a logical way that busy should work.  The manual implies that the two lines are equivalent and you could use a 3 wire SPI interface.  I designed the system with that in mind.  Clearly they are not equivalent.  Some of the figures do imply that the DOUT/RDY line is high Z and not driven but that is not the case (and a pull-up resistor did not fix the issue).  I am not sure then that is is really high Z as the scope does not reflect that aspect.

    BTW:  I am not sure how to use this line as an interrupt rather than polling (if the FT240X chip could even do that, which it cannot - it actually can kind of but I do not mind tying up a processor in a wait loop) as it does not appear to be set correctly for a low to high transition when the ADC conversion is completed.  But you can address that another day.

    I know that changing data sheets is difficult, but a better discussion of SPI interfacing would have helped me greatly.

    Thanks again for the quick response!

  • +1 in reply to David Kidwell
    TI__Guru** 112705 points

    Hi David,

    I'm glad to hear that you are now able to get things working.  As far as adding more detail to the datasheets, the ADS124S08 datasheet is already over 100 pages, so it becomes a question as to whether it is truly a datasheet or more of a user's manual.  In the end we try to balance this as much as we can.  This forum acts as a go between to help resolve these kinds of issues.  Simply put, we can improve the datasheets certainly, but we can't put all the nuances of the device in the datasheet.  There are just too many combinations of operation.

    The DRDY line is the desired pin to be used for determining the end of conversion as this is the only purpose for this pin.  It is not possible for the design of a multi-function pin to totally mimic the behavior of a single function pin.  In this case the DOUT/DRDY pin will make the high to low transition the same as the DRDY pin, but there is no mechanism to force the pin high after the data are read.

    Although it is not specifically stated that it would be better to use an interrupt system, it is stated multiple times that it is the falling edge of DRDY that signals that a new conversion result is ready to be read from the device.  Many of the timing diagrams show this as well.  Nowhere is it stated that the logic level signals a new conversion result has completed.

    Polling is mentioned in a couple of places.  One is with respect to using the RDATA command where the last conversion result is returned and not dependent on the current state of DRDY.  The second is when using multiple devices in section 9.5.5 on page 71 of the datasheet.  I've included a portion of the section below:

    "When connecting multiple devices to a single SPI bus, SCLK, DIN, and DOUT/DRDY can be safely shared by using a dedicated chip-select (CS) line for each SPI-enabled device. When CS transitions high for the respective device, DOUT/DRDY enters a tri-state mode. Therefore, DOUT/DRDY cannot be used to indicate when new data are available if CS is high. Only the dedicated DRDY pin indicates that new data are available because the DRDY pin is actively driven even when CS is high.

    In some cases, the DRDY pin cannot be interfaced to the microcontroller. This scenario can occur if there are insufficient GPIO channels available on the microcontroller or if the serial interface must be galvanically isolated and thus the amount of channels must be limited. In order to evaluate when a new conversion of one of the devices is ready, the microcontroller can periodically drop CS to the respective device and poll the state of the DOUT/DRDY pin.

    When CS goes low, the DOUT/DRDY pin immediately drives either high or low. If the DOUT/DRDY line drives low, new data are available. If the DOUT/DRDY line drives high, no new data are available. This procedure requires that DOUT/DRDY is forced high after reading each conversion result and before taking CS high. To make sure DOUT/DRDY is taken high, send a RREG command to read a register where the least significant bit is 1.

    Retrieving data using direct read mode requires knowledge of the DRDY falling edge timing to avoid data corruption. Use the RDATA command so that valid data can be retrieved from the device at any time without concern of data corruption by a new data ready."

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 10 points

    I do not want to belabor this point because your help fixed the problem.  However, the section you quote is titled "Interfacing with Multiple Devices", which I am not doing.  Also, the CS is tied low and the tri-state issue is when the CS goes high.  I assumed if CS is always low than DOUT/RDY and DRDY would mirror each other.  Another assumption is that the read command would immediately force DOUT/RDY to a high as new data is not ready immediately.  Thus, a read COULD make DOUT/RDY work for polling because you can look at that line without using the clock.  It is just the chip was not designed that way.  The only advantage to the current design is that you can read a previous value while conversion is occurring and know that the value was reliable.  This may be best in continuous mode rather than single shot but the synchronization to the conversions would be a challenge that is not clear how it can be done.  However, that advantage is very minor so it is not clear why the chip had this design feature.  You can always read a previous value in any case no matter what the DOUT/RDY line says and knowing that a previous conversion was complete you would know that the value was valid.  Thus, having the DOUT/RDY work as a level would make the chip more compatible to SPI.  A better explanation of how "can be used with only four or even three control signals"  would have helped me greatly.  Nevertheless, your explanation solved the problem.