cancel
Showing results for 
Search instead for 
Did you mean: 

COMP triggered ADC too slow

icecats
Associate

Hi,

1. [Part Number] NUCLEO-L432KC
2. [Environment] STM32CubeIDE 1.14.1
3. [Schematics] NA
4. [Details] I am trying to measure a fast pulse with the ADC (~3 us rise time). I would like to trip a comparator when the pulse starts to rise and then start an ADC (paced by a timer) to fill a buffer via DMA. After the buffer is full, I will send the data over UART for analysis.

The COMP and ADC are both connected to the same input. The COMP is set to trigger when the voltage exceeds that of an external input set to 0.04 volts. The ADC is connected to a timer that triggers at 2 Mhz.

I wait for HAL_COMP_TriggerCallback and then start the ADC with DMA:

 

void HAL_COMP_TriggerCallback(COMP_HandleTypeDef *hcomp) {
	if (hcomp == &hcomp1)
	{
		HAL_ADC_Start_DMA(&hadc1, (uint32_t*)voltage_buf, VOLTAGE_BUF_LEN);
		HAL_COMP_Stop_IT(&hcomp1);
	}
}

 


5. [Problem and Expected behavior] I have configured the above but I am seeing that the first ADC reading starts well after the pulse has started. Should I expect the time to start the ADC from a COMP to be this slow? I would like to measure the peak voltage which means that I need to capture at least some of the rising edge of the pulse.

6. [How to reproduce] I have attached the project files. Please see the attached oscilloscope view of the pulse and the plot of the ADC buffer values.

icecats_0-1712437905076.bmp

icecats_1-1712438593813.png

 


7. [Occurrence] 
8. [Sanity checks] Removed all blocking code in the interrupt callback to try to speed up. Googled around for "slow comparator start-up".

1 ACCEPTED SOLUTION

Accepted Solutions
Danish1
Lead II

HAL is multiple layers of software. Many arm-processor instructions need to br executed before the callback starts executing and your ADC starts sampling. I am not at all surprised that there is a delay.

You can make things faster by accessing the hardware directly, using the Reference Manual for your stm32. This describes the peripherals you have in detail, so it is necessarily complicated. But I find it much better documented than HAL.

Your application sounds like that of an oscilloscope. These often have “pretrigger” where they are sampling continuously into a circular buffer, then arrange for the sampling to stop a programmable time/number-of-samples after the trigger. This approach might allow you to live with the delays associated with HAL and still capture the whole pulse.

View solution in original post

2 REPLIES 2
Danish1
Lead II

HAL is multiple layers of software. Many arm-processor instructions need to br executed before the callback starts executing and your ADC starts sampling. I am not at all surprised that there is a delay.

You can make things faster by accessing the hardware directly, using the Reference Manual for your stm32. This describes the peripherals you have in detail, so it is necessarily complicated. But I find it much better documented than HAL.

Your application sounds like that of an oscilloscope. These often have “pretrigger” where they are sampling continuously into a circular buffer, then arrange for the sampling to stop a programmable time/number-of-samples after the trigger. This approach might allow you to live with the delays associated with HAL and still capture the whole pulse.

Thanks for the advice!

Indeed my application is similar to an oscilloscope.

I tried starting the ADC directly with the COMP interrupt by configuring the ADC timer to start when the COMP interrupt fired. I saw a minor improvement but still too slow. The rising edge of the signal is very fast!

I then started continuous ADC conversions as you suggested. When the COMP triggers, I start a timer to wait a bit to capture the falling edge of the signal. Then I process the signal. This works well and suits my needs!

icecats_0-1712524526814.png