Hello,
I'm using an STM32F767 to measure input frequencies, using 2 timers.
It's a bit tricky because these measurements must be synced to the SAI's audio sampling rate, AND input frequencies can be higher than the audio sampling rate.
It took me a while to figure out how to set up the timers to get there:
TIM3:
- input capture Ch1 = signal to measure
- clock source: internal clock (96MHz)
- trigger: external
- ETRF = audio sampling rate (e.g. 200 kHz (yes, that's unusual...))
- slave mode reset: resets the CNT
- triggers DMA to get the input capture register CCR1 to SRAM buffer
TIM4:
- external clock mode 2
- clock source ETRF = signal to measure
- trigger: external
- Ch1 = audio sampling rate
- slave mode trigger
- DMA triggered by input capture
From TIM3 I get the time of the latest input event (CCR1) within an audio sample (overcapture flag is willingly ignored in case of input freq > sampling rate),
from TIM4 I get the number of input events (CNT) from an audio sample.
So far so good, it works, that way I can measure input freq. with the timers' resolution, synced to the audio - most of the time...
BUT there's a problem in TIM3 with the IC / CCR1 to DMA:
Sometimes at input freq. > sampling rate when an input event happens very shortly after the audio sampling rate's counter reset and the DMA trigger, it seems that the DMA access to the CCR1 register comes too late, so that not the latest event of the last sample is captured, but already the first event of the new sample after the CNT reset.
Example:
- timer counter max at 96 MHz and 200 kHz sampling rate = 480 (okay, 0..479)
- input: 1 MHz -> 5 events within one 200kHz audio sample
- CCR1 values from latest event within sample should be around 479 - (480 / 5) = 383 up to 479
- but sometimes the CCR1 result in DMA is something between 0..3, so I think when the 1 MHz input signal's 1st event occurs very shortly after DMA trigger / CNT reset, that CCR1 is overwritten with that value
So I have checked the manuals & datasheets about any DMA timer specs and did not find anything.
Any explanations or ideas how to prevent that?
PS: I'm checking the STM32F7 to replace an existing FPGA design, and this is the first real problem...
