In a project I'm attempting to measure 4 frequency channels (range 10 to 500 hz) using TIM3 in the STM32F103.
During development I noticed the occasional missed capture event, or double capture events. I didn't pay much attention to these glitches thinking it was my hardware that glitched around a bit.
However, a completely other project with the same software has an identical problem. Then it must be software, right?
I've looked and it for a few days, and I think I found another problem in the timer capture hardware.
The erratas currently there:
In capture mode, when a capture occurs while the CCRx register is being read, the capture flag (CCxIF) may be cleared without the overcapture flag (CCxOF) being set. The new data are actually captured in the capture register
If a capture occurs while the capture register is being read, an overcapture is detected even though the previously captured data are correctly read and the new data are correctly stored into the capture register
But it seems unrelated to the reading of the capture registers because the frequency of my signal is relatively slow.
Following this I created a bare metal example, with 1 channel, and I found that when the capture flag is active longer than approximately 25 us, the capture interrupt never triggers.
- PC7 has a falling edge. EXTI is pending immediately, TIM3 has hardware filtering first.
- The EXTI triggers, and sets PD2.
- The EXTI runs a series of nops to delay the execution of TIM3 ISR.
- The TIM3 ISR does timer stuff.
- The TIM3 ISR clears PD2.
Now when I add one extra nop to the EXTI, the capture will occasionally miss. (probably when PC7 falls during systick)
As seen in this image:
Is this hardware, or a flaw in my software?
(void)register performs a dummy read to R0, I've checked.
The obvious workaround is to use software capture using the EXTI, but that would require the unfiltered EXTI to be at a very high nvic priority. Not ideal.
Chip: STM32F103RCT7 - GH239 93 - CHN GH 445