Input capture missing edges when running multiple timers

[ronnietango]

I have a NUCLEO-G0B1RE board generating 4 PWM signals at 10kHz using TIM1, which is working fine.

For my application I also need to be able to read 4-5 PWM signals in - so for now I am trying to read these same signals generated on TIM1 to test the input capture. I am using TIM2 and TIM3 in input capture mode with DMA for this purpose. TIM2 and TIM3 are run from the APB clock at 16MHz, with a prescaler value of 16-1.

Looking at the "Live Expressions" in the debugger, the results are *mostly* correct, but it appears that occasionally one of the timers will miss a transition, leading to the measured period being twice what it should be. 

Am I asking too much of the STM32G0B1RET6 part here, or (more likely) have I done something wrong/overlooked something which would prevent this?

I have attached my main.c file below - please let me know if I've missed any important information to help with identifying the issue and I'll update it.

Thanks!

[ronnietango]

Update: I was wondering if the HAL_TIM_IC_CaptureCallback() was getting choked up with multiple timers happening at once, so I've tried starting them all in individually in sequence (main.c attached again), but no change to the results (i.e. looking at the Live Expressions, the periods/duty cycles are as they should be most of the time, but they "jump" for a split second now and then).

[ronnietango]

Still struggling with this if anyone has any suggestions...

[waclawek.jan]

Suggestions? Don't use Cube/HAL, switch on compiler optimization, increase system clock frequency. You may perhaps contemplate using DMA to store captured data for "offline" processing.

16MHz system clock and 10kHz PWM means that you have 1600 system clock cycles per period. Minus time spent in the systick interrupt. Minus some cycles as the debugger "steals" some cycles for the live expressions. With 8 capture channels means, that you have in average less than 200 cycles per capture channel, and that's too few for Cube/HAL especially compiled with no or mild optimization. In your setup, you have at least one edge aligned for all channels, so that gets probably processed within one run of the ISR - this is not the case if those signals are not aligned, so for the generic case that will get worse.

JW