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.

ADS131 no SPI communications

Other Parts Discussed in Thread: DAC8564

I am trying to communicate ADS131E8 from STM32F0 microcontroller. I also have DAC8564 on the same SPI bus and successfully write data to it. CPOL_Low, CPHA_2Edge. Looks it configured correctly.

SPI clock speed is about 185 KHz, which is slow enough.

DVDD connect to the same power line as microcontroller (3.3V), AVDD connects to own 3V regulator.

I run from internal clock (CLKSEL connected to DVDD), RESET and PWDN are not connected (I tried connect them to DVDD with no result)

I trying to read register 0x00 by sending following bytes to SPI: 0x11 0x20 0x01 0x00 0x00 0x00 0x00

The only response I got from ADS131 is DOUT pin becomes force low while is CS Low. DRDY keeps high independent on START pin state.

Also, what is the minimal external components requirements to run digital communication? I tried to communicate with other chip on other PCB, but do not want assemble it completely.

What could be a problem?

  • Hello Dimitry -

    A couple items to consider:

    1.  Are you correctly using the power up sequence shown in Figure 23?

    2.  From your byte sequence:

    Dmitry Lyashenko said:
    I trying to read register 0x00 by sending following bytes to SPI: 0x11 0x20 0x01 0x00 0x00 0x00 0x00

    a.  Send RDATAC

    b. Send RREG of 2 registers beginning at register 0  (keep in mind the second byte of the read is n-1)

    3.  Are you tieing CS low or actively controlling it?


    While an SCLK speed of 185kHz will allow access for reading registers:

    1.  For RDATAC mode of operation -> The ADC data should be read back all data within the datarate period (between DRDY pulses to avoid data corruption)

    2. For RDATA mode of operation -> The ADC data can be read back across the next DRDY signal without data corruption.  However, you may potentially miss data this way which causes poor frequency analysis.

    If you continue to have problems, send us a scope capture of your SPI signals; these usually provide better debug capabilities than descriptions.