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.

ADS1271 - DRDY line change from input to output.

Other Parts Discussed in Thread: ADS1271, SN74LVC08A, ADS1278

I am using 6 ADS1271 with gating on the frame sync signal to pairs of converters. The FORMAT and MODE pins are tied (through a resistor) to 3.3V. The output of a SN74LVC08A gate drive the FSYNC line on pairs of converters, with one input a frame sync signal from a 6713 DSP and the other input a dedicated I/O pin. After turning on the clocks, the FSYNC/DRDY line appears to be in DRDY mode, the signal does not return to ground, and has the FSYNC signal superimposed on it. The length of 'contention' is directly related to the CLK rate. I am assuming the DRDY is active until the SPI mode power up sequence of filling the filters is complete and a reading is ready, then the converter is going to frame sync mode.

The question: what is required to get the FSYNC/DRDY pin into frame sync mode? Is this a feature?

The capture below shows the FSYNC signal not dropping below ~1.2V during start-up. This is the reason I believe the DRDY signal is active.

  • Hi Mark,

    I think that's exactly what's happening. During the first 76 conversions (settling time for Low-Power Mode), /DRDY seems to be fighting with the FSYNC pulses you're sending.

    Does this issue seem to resolve itself after the expected settling time?

    Regards,
  • Ryan,
    Thanks for your response.

    The FSYNC does appear to be normal after 'a' settling time, nearly 100mSec (from the scope shot). My FSYNC rate is 10kHz, so I'm expecting more like 12mSec to settle.

    Two questions:
    Why is DRDY being driven? My format pin is commanding FSYNC mode (low power).
    Why is it taking so long if my conversion clock is 2.66MHz and my SCLK is 666kHz?
  • Hi Mark,

    I'm still looking into this for you. I suspect that, even though the MODE and FORMAT pins are hard-tied to IOVDD, the /DRDY/FORMAT pin may be trying to power-up as an output, hence the contention. You may try waiting a few CLK periods before driving /DRDY/FSYNC. That still doesn't explain why the contention is lasting 100ms as your settling time after power-up should be about 12.4ms, but let's see if that helps.

    Also just for clarification, you FSYNC rate should be 2.66MHz / 4 / 64 = 10.390625kHz, not 10kHz.

    Best Regards,

  • Ryan,
    Our frequencies are the correct multiples, just rounding to get the expected ready time.

    I tried delaying the frame sync generation, and skipping the sync that occurs after we initialize the clocks (and DMA, we use the 6713 DMA to keep the last 64 readings in RAM) and did not change the 'ready' time. Temporarily running the CCLK at 16MHz is the only thing that has shortened the ready time and the switch (apparently) to frame sync mode.
  • Thanks, Mark.

    You mentioned that this occurs at start-up. Can you verify that both DVDD and IOVDD are present during this contention condition? There really is no start-up sequence requirement for this device, but if it's possible, can you bring up your DVDD supply before IOVDD and then drive the FSYNC?

    Regards,
  • Ryan,

    I took scope shots of our original power up sequence. (I assume by DVDD you are referring to the analog supply, in our case 5V.)

    We have the 5VA held off by the reset. I enabled the 5VA continuously, and got the same result. (The 5VA is at 3.6V when the 3.3V reaches starts up), this did not change the behavior.

    The shorter transition from SPI to Frame Sync mode is from running the CCLK at 16 MHz.

  • Hi Mark,

    Yes, my apologies - I had ADS1278 on my mind, which uses both an I/O supply and a DVDD supply. Your power supply sequencing shown in these scope captures looks fine.

    When do you begin sending CLKs relative to the power-up sequencing? The ADS1271 requires 12,288 CLKs to recognize a change in the MODE pin. Since the default is SPI Mode, the device may not change over to Frame-Sync Mode until the 12,288 CLKs have been counted. If it's possible, you may want to delay sending FSYNC until the 12,288 CLKs have passed and see if that avoids this contention altogether.

    Based on the last image above, /DRDY/FSYNC looks to me as if it is initially stuck at ~1.2V, indicating the device is stuck in SPI mode while CLKs are not present. Then /DRDY/FSYNC looks stuck between 1.2V and 3.3V, as if you have begun sending CLKs. After 129 conversions, it appears FSYNC is fully operational and toggles between 3.3V and 0V.

    Could you capture another scope capture, showing /DRDY/FSYNC, RESET, DOUT, and CLK?

    Best Regards,

  • Ryan,

    Here is our normal timing sequence (zoomed on the transition to 'fsync' mode):

    Timing until fsync starts:

    Timing until DRDY is released:

    Timing until converter start outputting data:

    Here the FSYNC has been delayed until after the converter comes out of SPI mode(?):

    We appear to have a 12mSec delay to data after frame sync starts, but this is on top of the 100mSec delay to transition  to frame sync mode. My previous post shows the time to exit SPI mode is dependent on the CClk rate.

  • Thanks, Mark. I will have the digital designer look at this today.

    Regards,

  • Mark - the designer and systems engineer are still looking into this. I will post their reply here as soon as I hear from them.
  • Hi Mark,

    The designers confirmed that the ADS1271 uses an internal power-on reset (POR) counter once the supplies are up. That counter equals 2^18 CLKs, which is 2^18/2.66MHz = 99.86ms in your case. During this time, we recommend tri-stating the pin on the processor side (or the digital buffer if you're using one) such that you are not driving the /DRDY/FSYNC pin on the ADS1271.

    After 2^18 CLKs, you can expect 12,288 CLKs (4.6ms) for the device to recognize a MODE change, followed by 128 conversions (12.4ms) for new data to be valid.

    I hope this clarifies everything for you. Let me know if you have any other questions.

  • Ryan,
    Thanks for your help, I think this answers the operational characteristics questions. I may be looking in the wrong place but is/will this be reflected in the data sheet?
  • Hi Mark,

    I will make a note of this for future datasheet revisions. Honestly, I'm surprised that it was not included to begin with since this feature is specified in several other device datasheets. If and when we get to revise the ADS1271 datasheet, I will make sure to add a section about the POR.

    Best Regards,