[STM32L4R5] how to configure TIM2 channel3 as PWM input capture, TI3 orTI4 as trigger input

[b.a.]

I want to capture several PWM signals, i.e. measure the pulse width

The reference manual gives an example for TIM2 TI1 that uses channel 1 and channel 2 to measure pulse width and period. Therefore SMCR.TS bits are set to use filtered TI1 as trigger/reset.
I want to do the same for TIM2 channel 3, but I don't see how I can set TI3 as trigger/reset source
Is it not possible to have the individual channels of TIM2 (or any timer) reset by different sources?

What I try to achieve is that a rising edge on TI1 starts CCR1 counting and have the value at a falling edge of TI1.
And I want the same for a rising edge on TI3, starting CCR3 counting and have the value at a falling edge of TI3.

How can I do this?

As far as I have seen SMCR allows only TI1 or TI2 as trigger source (or other timers, but that does not help here?)

[waclawek.jan]

> Is it not possible to have the individual channels of TIM2 (or any timer) reset by different sources?

There is only one counter in TIM2, and only one source to reset it (chosen by TIMx_SMCR.TS); and in that you can't select TIMx_CH3  as the trigger source.

If the edges of input signal are not too close to each other (i.e. input frequency is relatively low and pulses not too long or short), you can set TIMx_CH3 to capture on both edges, and from the captured values calculate both period and duty.

JW

[b.a.]

Thanks a lot for clarifying this for me - and the solution hint 🙂
It is indeed a quite slow PWM from Servo motor with feedback.

Thought about that as well, but I was not sure whether I read and interpreted the manual correctly...

Nice page you linked to, lots of interesting stuff!

[b.a.]

sorry @waclawek.jan for getting back to this...

I sometimes observed that the edges got mixed up, so I was wondering if I could add some safety here?
(Debugging is hard - if not impossible - with a 300Hz external signal)

I checked for the logic level using GPIOx->IDR of the corresponding pin, but it seemed to get messed up nevertheless - which I don't understand why this could happen?!?

So I thought, maybe I configure the timer to catch only rising edges, and on the event, in the ISR, I reconfigure to falling edge.

If that event occurs, reconfigure to rising, and so on, always switching the edge on the event.

Now, being quite sure that this works in theory, a little doubt is left whether this is a practically viable approach for capturing pulsewidth?

[waclawek.jan]

> I checked for the logic level using GPIOx->IDR of the corresponding pin, but it seemed to get messed up nevertheless - which I don't understand why this could happen?!?

> [...]

> Now, being quite sure that this [having active interrupt only on one edge, and then switching to other in the ISR] works in theory, a little doubt is left whether this is a practically viable approach for capturing pulsewidth?

To both the answer is, that details matter and the ISR must be fast enough so that you read the current GPIO level - and swap the active edge - before the pulse which caused the interrupt, ends (i.e. signal changes polarity). And this includes any sources of interrupt latency you have, mainly other interrupts of the same or higher priority.

Cube/HAL and inadequate compiler optimization levels make things worse.

JW

[b.a.]

I renounced to using HAL/Cube a long time ago... right after the first try to cerate sthg. with sub-ms precision...

Having pulses in the range of 300µs to 2.5ms, I am quite confident the pulse-width is not the issue.

Maybe jitter or sthg. else with the edges is not ok...

[waclawek.jan]

> I am quite confident the pulse-width is not the issue.

> Maybe jitter or sthg. else with the edges is not ok...

Well, "something with the edges" is, at the end of the day, "pulse width" again... You have to characterize your signal source, and act accordingly. If there are glitches on the edges, you should either process them using some sort of filtering at the signal source side, or e.g. using the digital filter in the timer's channels (see TIMx_CCMRx.ICxF).

> (Debugging is hard - if not impossible - with a 300Hz external signal)

That very well describes our craft.

JW