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.

ADS127L01: DRDY behaviour and conversion results reading

Part Number: ADS127L01

Hi folks,

we have four ADS127L01 in a daisy-chain configuration:

  • SCLK, MOSI, nCS: common for all chips
  • START: common for all chips
  • DRDY: OR-ed together and routed to a microprocessor
  • DAISYIN: grounded on the last chip, connected to DOUT of the previous chip on the others
  • DOUT: connected to DAISYIN on the following chip (and to the microprocessor's MISO from the first chip

The chips' configuration is LP, OSR 128, Wideband 1 filter, results are read using the SPI mode. On the following figure, there is an overview of the MCU-ADC interface behaviour:

The first two readings are successfull (all CRCs are correct), but on the last one, the data are corrupted (and further reading is stopped by the SW). The following figure shows a detailed view of reading #1…

…and the last figure shows a detailed view of reading #3:

The only difference I can spot is, that

  • on correct readings, the DRDY pulse after CS activation is either not present at all or is present before the first data bit is shifted out
  • on erroneous readings, the DRDY pulse is present after shifting out the first data bit.

Questions:

1. Do we handle the DRDY signal correctly (the OR-ing)?

2. What is the purpose of DRDY pulsing?

3. What means the negative DRDY pulse after CS activation - when START is low?

Thanks for ideas

  Jan

  • Hello Jan,

    Thanks for your interest in the ADS127L01!

    1. Are all four ADCs running off the same CLK input? If so, then their respective /DRDY pulses should be syncrhonized. This means that your uP would only have to monitor the /DRDY output from one device to know when data is ready for all four devices.
    2. /DRDY is an active-low signal to indicate when new data is available to read in the output shift register. It is meant to be used in asynchronous interfaces which do not have a continuously running SCLK.
    3. If the START pin is taken low, then I do not expect /DRDY to pulse since ADC conversions have stopped. Instead, /DRDY will transition high as soon as the START pin goes low, and it will remain high until the digital filter resets and settles (td(FLT) and td(NDR)). See Figure 85. Are all four START pins tied together?

    Please let me consult the digital designer to understand why this could be happening. Out of curiosity, can you tell which device /DRDY pin is actually pulsing while START is low? Is it all four of them, or maybe just one?

    Best Regards,

  • Hello Ryan,

    thank you for your answer.

    1. Yes, all four chips use the same 8MHz CLK input. I will pass this information to our HW department.

    2. I still do not understand what are the pulses good for. I would understand if the /DRDY signal would just drop down, when the conversion is completed – we would be able to use such signal as an interrupt request to the microprocessor, but the pulses – maybe we would have to insert an S-R latch?

    3. All ADCs behave in the same way: mesurements from my previous post were taken behind the OR gate, so in the following figure is shown the behaviour of START and /DRDY signals right at the ADC pins (the analogue /DRDY signal is measured at ADS127L01 pin, the signal from logic analyzer is processed by the OR gate):

    Thanks

      Jan Nárovec

  • Hi,

    another finding: edges on the following figure are almost exactly 16 µs far away:

    After adding a magic (*) delay between deactivation of START signal and reading the results, all readings are correct. Is this information somehow helpful?

    * The length of the delay depends on whether RDATA command is used or not: when used, > 5 µs is enough, when not used > 12 µs is neccessary.

     Jan Nárovec

  • Hello Jan,

    Understood, the issue seems clear to me now.

    First, regarding the synchronization, I should clarify that the /DRDY pulses will be only be synchronized if the START pin is shared among all four devices. Then you could pulse the START pin or send the START command to reset the digital filters and synchronize the conversions to the same clock cycle. You may already be doing this. If you are, and /DRDY pulses are synchronized as well, then you will not need the OR-gate.

    Can you confirm that all four START pins are going low together? Similarly, can you probe all four /DRDY pins and see whether it is one device or multiple devices which give a /DRDY pulse after START is low?

    /DRDY is an active-low signal that transitions low when new data is ready. However, it appears as a "pulse" because it will be cleared by the first SCLK falling edge. Meaning, as soon as you begin to read data, /DRDY will return high until the next sample is ready. I do not believe you need to latch the low state of /DRDY in your uP; you only need to monitor for the high-to-low transition to trigger your interrupt service routine and collect the data.

    Our designer initially thought that the issue could be related to the timing between the falling edges of START and /DRDY. However, your latest post illustrates another example in which START was taken low after /DRDY had been low for some time already, and you still see /DRDY pulse low again during your RDATA command. This still doesn't make sense to me, I will need to look into it further.

    Can you confirm which device /DRDY pin you are probing with the oscilloscope? You mentioned that the analog signal is taken before the OR-gate. I'm curious if all four devices are behaving this way while START is low.

    I'll update you again after speaking with our designers.

    Best Regards,

  • Hello Jan,

    Depending on when you bring START low relative to /DRDY, the converter may or may not complete the next conversion. It's still not clear to me how close to the previous /DRDY pulse you should bring START low in order to not see a subsequent /DRDY pulse. As you have noticed, in some cases, you do see another /DRDY pulse while START is already low, but in other cases you don't. Do you see any consistent relationship between /DRDY falling edge and START going low that produces this issue?

    Certainly, I think this is something we could explain better in the datasheet with more specific timing relationships between /DRDY and START going low. I will make a note to add this to the datasheet with suggested timing. Similarly, there is Figure 91, which shows the keep-out time before /DRDY falling edge. You cannot send SCLKs during this time without corrupting the data that is being loaded into the output shift register. This too could cause a potential issue while you are either reading data (as in the last image in your first post) or while you are still sending the RDATA command (as in your recent images).

    My suggestion would be the following - since you are only trying to read every nth sample, I would either:

    1. Count n-1 /DRDY pulses, bring START low immediately after, and delay for another data rate period before sending SCLKs. You may or may not see another /DRDY pulse during this time. Once n data rate periods have passed, then you can send RDATA plus enough SCLKs to read all 128 bits.
    2. Speed up the SCLK to complete the data read transaction within one data rate period. This does mean you must read every sample, but at least when you decide to read data, you will avoid corrupting data by finishing the read before the next sample. Check out the Excel calculator tool on the ADS127L01 prodcut page. The Multiple Device Configuration tab can be configured to calculate the number of daisy-chained or cascaded devices that can be used for a given interface and data rate. It looks like you would need an SCLK that is slightly faster than your CLK input frequency, about ~8.15MHz or greater.
    3. Scale down the external clock frequency to extend the data rate period. Do you need 28kHz of signal bandwidth?

    Let me know if you have any questions or comments.

    Best Regards,