STM32F3 : ADC => limitation on DEPTH

[alex31]

Hello,

I am using ADC on stm32F303 (branch 17.6 stable) , and i wads planning to use 3 channels with a depth of 2, this configuration works on STM32F4

On the F3, the mcu hangs in internal dma routines, until a raise depth to 12.

I have seen that in the testhal directory, depth is alway more or equal to 16 in continuous mode.

Is this an hardware DMA limitation, or a ChibiOS driver one ?

Another solution for me would be to start a conversion in an ISR, and use the result in another ISR, but the adcConvert api does not permit to
initiate a single conversion from ISR.

Alexandre

[Giovanni]

Hi,

Low depths cause more frequent interrupts, depth must be large enough to let CPU serve callbacks.

Giovanni

[alex31]

Yes, thanks, that was the problem.

I have fixed my problem launching startAdcConversion in an ISR to start conversion only in the window time where i need to sample data.

I didn't do that before, but i discover that if i set field circular to false, and (in case of adcV3) bit ADC_CFGR_CONT not set in CFGR register,
startAdcConversion will launch just one conversion with ISR triggered at end of conversion, and it's just what i needed

since i do only one conversion, i can even have DEPTH set to 1.

MCU no more hangs, and memory bandwidth is no wasted by useless DMA transfert.

It's the first time i use stm32F3, (used to F4 and F7), and performance is much lower on F3, on a severely jitter constrained application (brushless sensorless motor controller), every possible optimization count ...

Alexandre

[Giovanni]

Yes, one must be careful only with circular conversions.

Giovanni

[AdShea]

I've run into similar issues (using an F4) and have my own patched hal_adc.c that gets rid of the even depth requirement as I'm running triple ADC with 3 conversions each (depth = 3) but using direct triggering from the TIM2_TRGO event (while TIM2 is triggered by TIM1_TRGO to allow placing the sample start precisely). ChibiOS doesn't know about this so it looks like I'm asking for short continuous conversions, but what really happens is that when the timer triggers it does 9 conversions across the three ADCs then triggers an interrupt.

It'd be nice to add hardware triggering to the HAL as most mid-range and higher MCUs have it and it's essential for low-jitter sampling, but I'm not sure quite how to do so in a platform-agnostic way.

[Giovanni]

Hi,

There are already HW triggered demos under testhal using a GPT as trigger for an ADC.

Giovanni