2014-08-12 03:06 PM
Hello.
I'm following the procedure in AN2604 and trying to use an internal timer to measure the rtc frequency by looping back the rtc into a timer pin, in my case PA8 (Timer 1 channel 1), and then using PWM input capture mode.I was wondering if anyone has tried to do this before and been successful with it. I'm looking at the stm32 standard peripheral library pwm input example and have implemented my code using that as a basis. I can paste here but really I'd like to know if the idea is feasible at all given a 72Mhz system clock and the ~512Hz rtc signal to measure. #stm32f12014-08-12 05:13 PM
You can prescale the timer, 72 MHz / 4 = 18 MHz, 18 MHz / 512 Hz = 35156.25 which would fit in the 16-bit counter.
You might want to use Input Capture, and use that to count 1-8 periods via the input prescaler The F2/F4 have 32-bit timers, and direct internal connectivity to LSI/LSE2014-08-13 04:08 AM
Hmm. I do recall that input capture is a bit simpler than the pwm input capture. I'm getting oddly inconsistent results using pwm input capture but I've been assuming thats my misconfiguration of the capture or that my ISR isn't correct.
On the topic of precision, the rtc calibration requires measurements in the ppm range. Have you done this rtc calibration with input capture and gotten enough precision to accomplish the calibration? I can't seem to find anyone that has actually used this approach, either pwm capture or input capture, to self calibrate the rtc using the HSE.2014-08-13 06:12 AM
I've tinkered with it, depends on what clock you're trying to calibrate LSI/LSE. The former is wildly unstable, being dependent on voltage and temperature. I was playing with TCXO and GPS 1PPS sources.
I would use HSE to clock the part, not the VCO/PLL. I would measure a significant number of cycles, this could be done with Input Capture, and an IRQ/DMA of the CCRx, and then doing delta computations for the ticks per cycle. Consider also counting the external clocks (not the period), and do that over a longer observation window. A minute of 512 Hz would easily fit in 16-bit2014-08-14 03:58 AM
Hi Clive.
In this case we are using the HSE for the system clock.I'm not sure what you mean by measuring external clocks over a larger window. Could you explain more? Is that something that the input capture can be configured to help with?2014-08-14 05:07 AM
Externally clocking is another mode of the counter, you'd review the count periodically, by say using the SysTick or TIM (clocking the system via HSE) and counting off seconds, or longer periods.
Each second CNT should advance ~512, in a minute it should advance ~30720. It might be possible to latch this into CCRx registers, or use DMA In Input Capture you could measure the period (or 1,2,4,8 periods as permitted) in ticks of 8 MHz (HSE) 512 Hz / 4 = 128 Hz 8000000 / 128 = 62500 (fits in 16-bit) So with Input Capture, Input Prescaler of 4, Timer @ 8 MHz, you should be able to observe CCR1 advance by ~62500 at each CC1 interrupt.2014-08-18 07:10 AM
Ahh I see.
I'm trying this approach now. While I am seeing some odd amount of measurement error that I can only imagine may be due to using the timer prescaler, but can't explain, this approach has promise.So far it looks like measurement times on the order of 10s of minutes or more are required to get any level of accuracy nearing the >100ppm that is trying to be calibrated away. May end up having to go with some hardware to measure it more accurately although there could be some measurement error I'm introducing somewhere.To recap, I'm using:- TIM1 in external clock mode with a prescaler calculated to fit the total count inside of a 16bit number.- Systick (via the OS on the board) to provide a system time measurement.- Configure TIM1 to overflow at X minutes of pulses + prescaler- Upon ISR for TIM1 overflow the system time is captured2014-08-18 11:31 AM
And of course I mean <100ppm, not >100ppm.