2023-06-03 11:13 PM
I try to measure frequency and duty of a PWM input signal with an STM32G474. For this i have selected the combined channels option "PWM input on CH2" for Timer 15 in CubeMX.
The measurement works well, as long as the input signal is not to slow. When the input frequency drops below 1300Hz, i get wrong frequency values. Obviously this is because the 16 Bit timer runs over: I use the 170MHz system clock divided by 2. dividing 85.000.000Hz by 0xFFFF results in about 1296Hz. When i apply a frequency of say 1200Hz, the time between two rising edges used for period detection is more than 0xFFFF timer ticks. So the timer counter wraps around and I get only the 16bit fraction of a number slightly above 0xFFFF, corresponding to a very short period or respectively a very high frequency. Of course the measurement range can be controlled by adjusting the timers prescaler. The problem is, that I need a criterion if the measurement was valid, of if overrun had occurred.
In my understanding, the PWM input mode uses the reset mode to reset the counter on the trigger event defining the period (not on the second edge of the duty event). So I had the idea, that the timer never wraps around when the PWM input signal period is shorter than 0xFFFF timer ticks. In this case, the PeriodElapsed Interrupt could by used as a criterion that the PWM measurement has failed. It shows, that the interrupt is triggered even when the PWM signal is mach faster than 1300Hz, so this criterion is not usable.
Is there a way to detect overrun during PWM input?
Solved! Go to Solution.
2023-06-04 01:10 AM - edited 2023-11-20 04:04 AM
Please use terminology estblished by Reference Manual, instead of whatever random names invented by Cube/HAL. There's no PeriodElapsed interupt; instead, it's the interrupt as consequence of Update event. And that then allows you to read the RM to find out how that event/interrupt is generated and textually search for related features.
In particular, what you see are Update events as consequence of the Reset through slave-mode controller:
And, knowing that, you can then separate this sorce of Update from the "genuine" Update due to overflow, by setting TIMx_CR1.URS:
JW
2023-06-04 01:10 AM - edited 2023-11-20 04:04 AM
Please use terminology estblished by Reference Manual, instead of whatever random names invented by Cube/HAL. There's no PeriodElapsed interupt; instead, it's the interrupt as consequence of Update event. And that then allows you to read the RM to find out how that event/interrupt is generated and textually search for related features.
In particular, what you see are Update events as consequence of the Reset through slave-mode controller:
And, knowing that, you can then separate this sorce of Update from the "genuine" Update due to overflow, by setting TIMx_CR1.URS:
JW