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.

ADS1259 maximum SPI clock

Other Parts Discussed in Thread: PGA280, ADS1259

Customer is using the ADS1259 ADC. Also on the SPI bus are two AD5760 DACs, a PGA280, and the SPI Master is a FPGA.

Is it OK to run the SPI clock at a higher frequency than the max frequency of the ADS1259, if the ADS1259 chip select is not active (specifically 20MHz SPI Clock)?

In their design, the problem appears to be after accessing the DAC, the ADS1259 doesn't respond to the Start command once in a great while. When the ADS1259 doesn't respond, the DRDY signal goes low to signal the FPGA to read out the data, but doesn't stay low for the 7 or 8 clocks that they normally see. DRDY goes back high on the first clock.

  • Hi Tom,

    It shouldn't be a problem to use a faster SCLK when addressing other devices on the SPI bus.

    Regarding the behavior of /DRDY, it should return high after the first SCLK when reading data (in "Gate control" mode, i.e. continuous conversion mode).

    A couple questions to help troubleshoot the issue:
    - Are they using "gate control" mode or "pulse control" mode?
    - Does the data look invalid when this occurs?
    - Does /DRDY go low again after waiting another conversion period?

    Best Regards,
    Chris
  • - Are they using "gate control" mode or "pulse control" mode?
    If the DRDY is going high on the first clock does this mean we are in GATE Control mode? And if so, if we send another START command is this a problem.
    From what I understand Gate Control is continuous mode and conversions continue until the START pin is taken low or stop command is set.
    - Does the data look invalid when this occurs?
    the Data the we get looks to be correct
    - Does /DRDY go low again after waiting another conversion period?
    No, that is the problem. /DRDY drives our system, and we can see that the START commend is sent, when we read the last value out, but we never see the /DRDY go back low. But if we are truly in GATE control, should we be sending another start command?
    Thry did an experiment where everything is the same except where the SPI clock is updated for the DAC, we now hold the SPI clock low.
    They are still driving the MOSI line with the same data. The system never fails. ( But of coarse we are not clock the data into the DACs.
    They also did a similar experiment where we drove the SPI clock at 20MHz for the DAC access(s), but just wrote zeros to the DACs. Again the ADC continues to work.
    It really seems as if it is a combination of the DAC clock and a value in the range of 32,780 - 38,300 being written to the DAC that causes the ADS1259 to not response to the START command.
  • Hi Tom,

    In response to the new questions above...

    Tom Saluzzo said:
    If the DRDY is going high on the first clock does this mean we are in GATE Control mode? And if so, if we send another START command is this a problem.

    Yes, /DRDY only returns high in GATE Control mode (when reading data). In PULSE Control mode, /DRDY only returns high when sending a START command.

    Sending START in GATE Control mode will restart the current conversion, which may delay the next conversion result.

     

    Tom Saluzzo said:
    No, that is the problem. /DRDY drives our system, and we can see that the START commend is sent, when we read the last value out, but we never see the /DRDY go back low. But if we are truly in GATE control, should we be sending another start command?

    No, in GATE Control mode the ADS1259 is continuously converting until you stop the conversions. Have you read back the CONFIG2 register to verify the mode you're using?

     

    Tom Saluzzo said:
    It really seems as if it is a combination of the DAC clock and a value in the range of 32,780 - 38,300 being written to the DAC that causes the ADS1259 to not response to the START command.

    Will the ADS1259 respond to anything at this point, such as a read register command?

    Has the ADS1259 been powered-down? (This would make it non-responsive)

    Have you looked at the SPI communication with a logic analyzer to make sure that the SPI settings are correct when you re-establish communication with the ADS1259?

     

    Best Regards,
    Chris