ADS8688 SPI communication issues with STM32F446RET6 - Reading random/garbage values

[Shivabalan]

Hello everyone,

I'm currently working on a project using an ADS8688 ADC IC and an STM32F446RET6 microcontroller.

I'm encountering an issue where I'm consistently reading random or garbage values over SPI, even when I'm applying stable input voltages to all 8 channels of the ADS8688. I've verified the input voltages with a multimeter, and they are as expected.

Here's a brief overview of my setup and what I've tried so far:

Hardware:

• ADC: Texas Instruments ADS8688 (8-channel, 16-bit, SAR ADC)
• MCU: STM32F446RET6 (using one of its SPI peripherals)

Problem Description: When I apply known DC voltages to the input channels of the ADS8688, the data I receive over SPI from the STM32F446RET6 is not the expected digital conversion result. Instead, it appears to be random or corrupted, showing no correlation with the input voltage.

What I've Checked/Tried So Far:

1. SPI Configuration (STM32F446RET6):

   • SPI Mode: I'm using SPI Mode 1 (CPOL=0, CPHA=1), which is typically recommended for the ADS8688.
   • Clock Prescaler: I've experimented with different clock prescalers (2,8, 16) to ensure the SCK frequency is within the ADS8688's specifications and the STM32 can reliably sample.
   • Data Size: Configured for 16-bit data transfer.
   • LSB First/MSB First: Configured for MSB First, as expected for the ADS8688.
   • CS PIN:GPIO toggling for CS.

2. ADS8688 Configuration:

   • I've tried basic configurations, ensuring the device is powered up correctly and the internal reference is enabled (or an external one if used).
   • I've sent commands to configure the input range (e.g., ±10.24V, 0−10.24V).

3. Wiring & Connections:

   • Triple-checked all SPI lines (SCK, MISO, MOSI, CS) for continuity and correct connections between the STM32 and ADS8688.
   • Ensured proper grounding.
   • Power supply for both ICs is stable and within specified ranges.

4. Code Logic:

   • CS Control: Ensuring CS is pulled low before initiating SPI transfer and pulled high after the transfer is complete.
   • Read/Write Sequence: Following the datasheet's timing diagrams for read and write operations, especially for initiating conversions and reading data registers.
   • Dummy Reads/Writes: Performing dummy reads/writes as per the datasheet's recommendations for command cycles and data retrieval.

Specific Questions/Areas for Advice:

• Are there any common pitfalls when interfacing the ADS8688 with an STM32 that I might be overlooking?
• Could this be a power supply decoupling issue, even though the supply looks stable?
• Are there specific register configurations on the ADS8688 that are critical for initial sanity checks or basic functionality?
• Has anyone experienced similar "random/garbage" values and found a specific solution (e.g., related to SPI clock phase/polarity, timing, or sample rate)?
• Any suggestions for debugging SPI communication at a lower level (e.g., using an oscilloscope on the SPI lines)?

  Hello everyone,

  I'm currently working on a project using an ADS8688 ADC IC and an STM32F446RET6 microcontroller.

  I'm encountering an issue where I'm consistently reading random or garbage values over SPI, even when I'm applying stable input voltages to all 8 channels of the ADS8688. I've verified the input voltages with a multimeter, and they are as expected.

  Here's a brief overview of my setup and what I've tried so far:

  Hardware:

  • ADC: Texas Instruments ADS8688 (8-channel, 16-bit, SAR ADC)
  • MCU: STM32F446RET6 (using one of its SPI peripherals)

  Problem Description: When I apply known DC voltages to the input channels of the ADS8688, the data I receive over SPI from the STM32F446RET6 is not the expected digital conversion result. Instead, it appears to be random or corrupted, showing no correlation with the input voltage.

  What I've Checked/Tried So Far:

  1. SPI Configuration (STM32F446RET6):

     • SPI Mode: I'm using SPI Mode 1 (CPOL=0, CPHA=1), which is typically recommended for the ADS8688.
     • Clock Prescaler: I've experimented with different clock prescalers (e.g., /2, /4, /8, /16) to ensure the SCK frequency is within the ADS8688's specifications and the STM32 can reliably sample.
     • Data Size: Configured for 16-bit data transfer.
     • LSB First/MSB First: Configured for MSB First, as expected for the ADS8688.
     • NSS Management: Using software NSS control (GPIO toggling for CS).

  2. ADS8688 Configuration:

     • I've tried basic configurations, ensuring the device is powered up correctly and the internal reference is enabled (or an external one if used).
     • I've sent commands to configure the input range (e.g., ±10.24V, 0−10.24V).

  3. Wiring & Connections:

     • Triple-checked all SPI lines (SCK, MISO, MOSI, CS) for continuity and correct connections between the STM32 and ADS8688.
     • Ensured proper grounding.
     • Power supply for both ICs is stable and within specified ranges.

  4. Code Logic:

     • CS Control: Ensuring CS is pulled low before initiating SPI transfer and pulled high after the transfer is complete.
     • Read/Write Sequence: Following the datasheet's timing diagrams for read and write operations, especially for initiating conversions and reading data registers.
     • Dummy Reads/Writes: Performing dummy reads/writes as per the datasheet's recommendations for command cycles and data retrieval.

  Specific Questions/Areas for Advice:

  • Are there any common pitfalls when interfacing the ADS8688 with an STM32 that I might be overlooking?
  • Could this be a power supply decoupling issue, even though the supply looks stable?
  • Are there specific register configurations on the ADS8688 that are critical for initial sanity checks or basic functionality?
  • Has anyone experienced similar "random/garbage" values and found a specific solution (e.g., related to SPI clock phase/polarity, timing, or sample rate)?
  • Any suggestions for debugging SPI communication at a lower level (e.g., using an oscilloscope on the SPI lines)?

[waclawek.jan]

 hspi3.Init.CLKPolarity = SPI_POLARITY_LOW;
 hspi3.Init.CLKPhase = SPI_PHASE_1EDGE;

 I don't use Cube, but this to me does not sound like

> I'm using SPI Mode 1 (CPOL=0, CPHA=1)

Also, how exactly are the lines connected, which ADC pin to which STM32 pin?

How is that accomplished physically? A dedicated PCB, or some devboards connected by flying wires?

Also, how are the SPI pins set in GPIO? Very often, setting highest OSPEEDR setting with SPI (especially SCK) is wrong, as that may lead to ringings and thus unintended multiple clocks.

Ground arrangement is of paramount importance, in case of flying wires each and every SPI line has to have its own ground/return, the most important is to keep SCK separated.

I personally would start with no attempt to program the ADC (i.e. transmit only zeros into ADC - see in the ADC's DS what's the consequence of that, I did not investigate that deeper if that's the "do nothing"), and transfer data from a single channel, perhaps even clocking "manually", bit-banging the chipselect and clock (maybe even literally manually, manipulating GPIO registers in debugger), while observing the individual lines (if you go really slow, even LEDs would suffice - normally a logic analyzer would be used, or a multichannel oscilloscope). If you have a logic analyzer/oscilloscope, then just compare the observed waveforms with what's in the ADC's datasheet. The first thing to look for would be the first 16 bits outputting from the ADC being all zeros.

JW

PS. Out of curiosity, what tool did you use to prepare that initial post?

[TDK]

Here's how the data sheet says to read a sample:

 

You can see it sends 16 bits and reads another 16 bits. You don't do this in your code.

 

Your ADS_Read_All_Raw function sends and receives 16 bits at a time, not 32, so it never even receives data.

[waclawek.jan]

> Your ADS_Read_All_Raw function sends and receives 16 bits at a time, not 32, so it never even receives data.

Well, but then it should be receiving all zeros, shouldn't it.

JW

[TDK]

Yes.

Looking again, the code does actually send and receive 2 16-bit values as the word size is 16-bit. But since the arrays are sized as 1x uint16_t, there is an out of bounds write happening. It could be clobbering the loop variable.

[Andrew Neil]

1. Use an oscilloscope to look at the SPI lines - are they working? are they clean?
    
2. Use the scope or an analyser to capture the interaction between STM32 & ADC - does it correspond to the datasheet?

 

PS:

---

@Shivabalan wrote:

• Are there specific register configurations on the ADS8688 that are critical for initial sanity checks or basic functionality?

---

That would be a question for TI:

https://www.ti.com/product/ADS8688#support-training

 

TI have a Linux driver for this part: https://www.ti.com/product/ADS8688#software-development - have you tried looking at that?