Several question regarding STM32Fx (TIMx,DMA,ADC)

[PButc.1]

Hello,

I have few questions regarding the TIMER capabilities confgured as input capture. According to the reference manual, the direct input capture of TIMxCH1 in conjunction with a TMxCH2 which is configured as "indirect input capture mode" along with some slave controller reset settings, I am able to read for example on the CCR1 the period and on CCR2 the pulse witdh for pwm measurement. Is this approach only applicable for CH1 and CH2 when taking a global look on CH1,2,3,4 of a timer? On CubeMx I don't see any options to extend it to CH3 and CH4 as there is only one trigger source. Is this a limitation of the timer architecture or just a feature not provided by CubeMx as you can configure that manually in SW? According to the timer block diagram, it looks like out of 4 channels in total for one timer, you can use CH1 and CH2 as a pair (same to CH3 and CH4) in direct and indirect input caputre mode. Is that possible?

Is it possible to use this functionality without any interrupt or DMA overhead? According to the manual, it claims that the overrun flag is set, when reading the content out of the CCR registers is too slow. But anyhow I am able to get the "latest" values available when I just read that CCR register taking into account that depending on each reading cycle some data packages which could change inbetween are probably missed? Is it possible to use it in such a way or is the functionality automatically disabled when you don't manage to read the overrun flag fast enough?

When talking about "direct input capture mode" for only one channel, is it possible to achieve the same behaviour like 2 timer Channles in direct and indirect mode confgiuration" (as described above) when I attach a DMA only on one "direct input capture mode" timer channel? Here I could configure the DMA in circular mode and fill the content on both polarities (rising as well as falling edges). From time to time the application could read the buffer in RAM from the DMA and recalculate the period and pulse width. Is this approach possible?

Is the accuracy degenerated when using the internal clock for the input measurement?

I would like to know when using the ADC along with the DMA, I guess in circular mode, whether it is possible to start a ADC conversion only on specific selected channels from a bigger ADC channel group? Samples are stored in a RAM buffer from the DMA and later on, depending on application context a new ADC conversion group is triggered till the whole buffer is full. For example, I am using 12 ADC channels from ADC1 and I would like to split them into 4 groups (3 ADC channels per group). So depending on the application context, I start with group 1 conversions. When the sampling finished for those dedicated ADC inputs, the buffer contains the first three hald words in the buffer. Later on (+100ms), I continue and start with group 2 ADC conversions. Again, after some time, I start with group 3 and group 4 which will fill the buffer completly in the RAM (12 x half word elements). Is it possilbe to implement such a behavoir as I would like to avoid blocking polling mode as well as pure interrupt routines.

[waclawek.jan]

Which STM32?

As you've noticed, CH1/CH2 and CH3/CH4 are pairs, in regard of the possibility to "steer" one's physical input into the other's processing logic.

You can capture on the opposite edges using either pair, but only CH1 allows you to perform the counter reset.

Capturing on both edges on one channel and storing using DMA may be possible, but when the edges are close to each other (at extreme duty) there may be not enough time to do it for both.

ADCs vary between STM32 families. What you describe might be possible as in some (most? all?) families there is significant automatism built into the ADCs as far as scanning sequences of channels, but you'll need to reconfigure between conversion batches. It may be as simple as writing to one or two registers, though.

The best thing you can do is, experiment.

JW

[PButc.1]

Hello @Community member​ ,

thanks for your feedback. So when I use one timer which contains 4 channel with direct and indirect capture mode capabilities, which are used as pairs, lets assume Channel 1 (direct mode) + Channel 2 (indirect mode) and Channel 3 (direct mode) + Channel 4 (indirect mode) for input capturing, I am only able to perform a counter reset via Channel 1 on both pairs? This is not possible for Channel 3 + Channel 4 where the counter reset is initiated by Channel 3 for example because I don't see that configuration anywhere on CubeMx? So generally speaking, you can efficiently perform input capturing only on Channel 1 + Channel 2 for one timer with 4 channels because the counter reset is only initiated by channel 1, is that assumption correct? I was thinking you can use 1 pair for each input capture measurement, but for channel 3 + channel 4 the counter is not reset by channel 3. So, you need to rely completely on channel 1 as a reset source, is that correct? As a result of this, pair 2 (channel 3 + channel 4) is not really useful as an independant input capture measurement, is that right?

One question you left open for the timer functionality in my first post:

If you use input capturing with two channels, lets assume with channel 1 (direct mode) + channel 2 (indirect mode) where the counter is reset with channel 1, is it possible to read the data without any DMA or interrupt overhead? According to the manual, it says that there is an overrun flag in case you don't read the data fast enough. Does the timer functionality gets disabled automatically by the HW architecture of the timer or can I still read the CCR register in order to catch the latest values from the measurement with the knowledge that I maybe missed several packages between each CPU ready cycle (for example every 800 ms) although the the frequency on the input capture channel is much faster and changing inbetween?

[waclawek.jan]

Overcapture just sets the flag, it won't stop anything.

However, with reading the two CCR at "random moment", you may read two inconsistent values, especially given you talk about "high frequencies".

One more warning, the reset mechanism involves a delay handwaved (read: not just not specified, not even mentioned) by ST, leading to period readings a few cycles shorter.

JW