ADS8665: Getting samples at fixed period without needing to synchronize CS and CLK signals

Sure! I will share how I received fixed sample rate using stm32 hardware timers. But as I said, it would be great if I can somehow give this job to ADS8665. Current spi output clock frequency over RVS pin is very high. It would be awesome if there's any way to reduce it and also keep the data and clock in sync. 

Hello!

If you're interested, I found a way to achieve a periodic sampling rate from the ADS8665 ADC using STM32 configured as an SPI slave, all without any CPU involvement. In this setup, although STM32 is not the SPI master, it essentially controls the timing signals—mimicking master behavior to bit-bang data from the ADC. Here's how I connected everything:

I'm using TIM2 to generate the Chip Select (CS) signal for the ADS8665. TIM2 not only controls the CS line but also acts as a trigger source for TIM8, which is responsible for generating the SPI clock. Each time the CS line is toggled, the ADS8665 captures a sample from its analog input. Shortly after CS goes active, TIM8 is triggered to output a 50% duty cycle PWM with 16 pulses, which serves as the SPI clock signal. Below is how it's configured in STM32CubeIDE:

Both timers run at 108 MHz, and by dividing this frequency by 2250, I achieve the desired 48 kHz sampling rate. In TIM2, Channel 1 is configured to generate the CS signal after 225 timer counts. Channel 4, while not connected to any physical output, is used internally to trigger TIM8. Its compare value is set to 725 to ensure that the clock signal generated by TIM8 is center-aligned with the active CS state. The output trigger source is configured as OC4REF.

TIM8 is configured in slave mode, with its trigger source set to ITR1, which links it to TIM2. Note that trigger mappings like ITR1 can vary between STM32 models, so it's important to consult the reference manual to verify which timer connects to which ITR input. TIM8 is set to One Pulse Mode and configured with a repetition counter of 16, so it generates exactly 16 clock pulses per trigger. The clock signal is output on Channel 2 at 864 kHz. For a 50% duty cycle, I set the PWM pulse width to 62, which is half of the period value (125).

On the SPI side, I configured the peripheral in Receive-Only Slave mode with a 16-bit data size. I enabled DMA and NVIC interrupts, and set up the DMA in circular mode with a half-full threshold and half-word (16-bit) data width.

There are a few important points to handle correctly in code.

1- You must initialize the slave timer (TIM8) before the master timer (TIM2) in main.c. This ensures proper synchronization and prevents premature triggering.

int main(void)
{

  /* MPU Configuration--------------------------------------------------------*/
  MPU_Config();

  /* MCU Configuration--------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */
  MX_TIM8_Init();
  MX_TIM2_Init();
  /* USER CODE END SysInit */
  
  //rest of the initialization.....
}

2- The DMA buffer used for SPI data reception must be properly memory-aligned. If it's not aligned, the data may be misaligned by 1 byte, which can cause incorrect reads and even buffer overflows.

// This may not work
struct {
	volatile uint8_t a;
	volatile uint8_t b;

	uint8_t raw_buf[K * 2];
} data_str;

// This does work
struct {
	volatile uint8_t a;
	volatile uint8_t b;

	uint8_t raw_buf[K * 2] __ALIGNED(4);
} data_str;

3-To ensure a reliable startup, the initialization sequence is important. You should first start SPI DMA reception, then start the slave timer (TIM8), and finally start the master timer (TIM2). This order guarantees that all components are ready before signals begin to flow.

void addaq_data_init() {
	HAL_SPI_Receive_DMA(&hspi2, data_str.raw_buf, BUF_SIZ_BYTES * 2);
	osDelay(1);
	HAL_TIM_PWM_Start(&htim8, TIM_CHANNEL_2);
	HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1);
}

With everything set up correctly, the system works flawlessly—as confirmed by the waveform captured on the logic analyzer.

If you notice that the first clock pulse appears too early, it's because TIM2 (the master) was started before TIM8 (the slave). Simply reversing the initialization order—starting TIM8 before TIM2—resolves this issue.

After making that adjustment, I received the expected ADC value of 0x7FE0 (which corresponds to 0x7FE = 2046), confirming that the data is being correctly written into the raw DMA buffer.

Cool!

Thank you for letting us know!