How do I measure frequency using MCU timers? (STM32F0)

[technix]

Two of my projects need to measure frequency of some clock signal and act upon it:

* M107v1 USB Color Sensor: it uses a STM32F042F6P6 to measure the frequency output of TCS3200 color sensor relative to its own 8MHz ceramic resonator (which also provides its own 48MHz system clock and USB clock over a PLL,) then turn it into USB HID packets for host computer to consume.
* M177v4 Raspberry Pi GPS HAT: it uses a STM32F030F4P6 to measure the nominally 32768Hz frequency output of DS3231 TCXO RTC relative to PPS pulse from a GPS module, then in turn trim the RTC clock with that.

How to do that? I do know it needs chaining two clocks up together, but how?

[thinkfat]

There are variants of the STM32F0 which can discipline their internal RTC with an external pps pulse. You could just do that and suppress the external RTC entirely. Or is hold-over with GPS loss so critical that you need an external, tcxo controlled RTC?

EDIT TO ADD:
Regarding frequency measurement, you could use one timer in external clock mode to count edges from the color sensor output, and another timer to provide a capture event. The timers in the STM32F0xx can also be used to measure pulse width of an external signal, if that's precise enough for you.

Updated:
I didn't find STM32F0xx that would sync against a PPS signal, only 50Hz or 60Hz, which is ideal for applications where you have a mains input somewhere. Not for GPS though.

[PCB.Wiz]

Two of my projects need to measure frequency of some clock signal and act upon it:

* M107v1 USB Color Sensor: it uses a STM32F042F6P6 to measure the frequency output of TCS3200 color sensor relative to its own 8MHz ceramic resonator (which also provides its own 48MHz system clock and USB clock over a PLL,) then turn it into USB HID packets for host computer to consume.
* M177v4 Raspberry Pi GPS HAT: it uses a STM32F030F4P6 to measure the nominally 32768Hz frequency output of DS3231 TCXO RTC relative to PPS pulse from a GPS module, then in turn trim the RTC clock with that.

How to do that? I do know it needs chaining two clocks up together, but how?

This is unclear, as you mention 2 projects, but then give examples that appear to already do what you ask ?
Can you ask a better question ?
Do you already have M177v4 Raspberry Pi GPS HAT & M107v1 USB Color Sensor both connected to a Pi ?

[technix]

This is unclear, as you mention 2 projects, but then give examples that appear to already do what you ask ?
Can you ask a better question ?
Do you already have M177v4 Raspberry Pi GPS HAT & M107v1 USB Color Sensor both connected to a Pi ?

These two projects are irrelevant, however in both projects a frequency measurement mechanism with a 20-pin STM32F0 is needed. Those are the goals of the projects, but at their cores the frequency measurement mechanism has yet to be implemented.

There are variants of the STM32F0 which can discipline their internal RTC with an external pps pulse. You could just do that and suppress the external RTC entirely. Or is hold-over with GPS loss so critical that you need an external, tcxo controlled RTC?

The RTC is not for the STM32 to use, instead it is for the Pi as a stratum 1 NTP server. The STM32 trims the TCXO against the GPS when it gained a fix, so the Pi can have a second PPS source when GPS is lost.

Regarding frequency measurement, you could use one timer in external clock mode to count edges from the color sensor output, and another timer to provide a capture event. The timers in the STM32F0xx can also be used to measure pulse width of an external signal, if that's precise enough for you.

Any pointer on implementing that edge counter + capture event structure?

[PCB.Wiz]

Any pointer on implementing that edge counter + capture event structure?

What frequency range do you plan to measure, and with what precision and measurement rate ?

If you know the frequency under test (like the 32kHz example you quote)  you can use a simple capture timer, to count cycles.
eg In another thread, it was shown 61 seconds of 32.768kHz resolves to 0.5ppm, and a 16b timer is enough to capture the expected deviations, as you know the MSBs are stable.

If you want a more generic Frequency Counter, (Reciprocal Counter) then you may need two capture systems, one for Time, and one for Cycles
Both channels capture over some whole number of Fi cycles, (on the same edge) and you then determine Frequency = Cycles/Time
Above some MHz limit, you will need an external prescaler

This has a better dynamic range on parts with a one-shot Dual Chan arm->capture design,  which is rare on MCUs, but can be created in parts with Configurable Logic cells.

[thinkfat]

There are variants of the STM32F0 which can discipline their internal RTC with an external pps pulse. You could just do that and suppress the external RTC entirely. Or is hold-over with GPS loss so critical that you need an external, tcxo controlled RTC?

The RTC is not for the STM32 to use, instead it is for the Pi as a stratum 1 NTP server. The STM32 trims the TCXO against the GPS when it gained a fix, so the Pi can have a second PPS source when GPS is lost.

OK, so the DS3231 will not interface with the I2C of the Pi, only providing a PPS signal? Otherwise - you will need to arbitrate accesses between the micro and the Pi to the DS3231, because it only has one control interface.

Also, the possibilities to "trim" the TCXO are not very extensive, it seems there is only an "Aging Offset" register that you can use, signed 8 bit value, LSB worth 0.1ppm of change, so at max you can trim +12.7ppm / - 12.8ppm.

Regarding frequency measurement, you could use one timer in external clock mode to count edges from the color sensor output, and another timer to provide a capture event. The timers in the STM32F0xx can also be used to measure pulse width of an external signal, if that's precise enough for you.

Any pointer on implementing that edge counter + capture event structure?

Well, just have a look at the register manual. For example, for the PPS sync, you could use e.g. TIM1, configure the counter into free-running auto-reload mode, connect each PPS signal to a TIM1_CHx input and configure the two linked capture/compare stages to capture the counter at each rising edge of the PPS pulse. Then, subtract the two captured counter values. If the result changes, you have a drift and you can use that information to trim the RTC.

[MosherIV]

Hi

Generally speaking, there are 2 methods for measuring freq
1. Gated period method. Already described by most people, set up 1 timer say to 1 secound, use 2nd counter to count the edges of signal until 1st timer triggers. The count is the freq
2. Recipricle method. Set up 1 very high speed clock to a counter, start and stop the counter on the rising edge of the input signal. Divide 1 by the count x hs clock period.

[PCB.Wiz]

Hi

Generally speaking, there are 2 methods for measuring freq
1. Gated period method. Already described by most people, set up 1 timer say to 1 secound, use 2nd counter to count the edges of signal until 1st timer triggers. The count is the freq
2. Recipricle method. Set up 1 very high speed clock to a counter, start and stop the counter on the rising edge of the input signal. Divide 1 by the count x hs clock period.

Close, the more general Reciprocal counter captures time over some whole number of Fi cycles, usually larger than some nominal 'gate time'.
If you capture the SysCLK rather than start & stop timers, you can use multiple results to improve precision, as you do not drop any SysCLKs

Measuring over a single cycle, loses precision at high frequency inputs, whilst a design that measures whole cycles in say (>200ms) will give N digits/second. independent of Fi

As an example, let's measure 33Hz with a 10MHz SysCLK and a (>200ms) gate time.
That will capture 7 whole cycles, in actually 212.1212121ms, the 10M SysCLK capture is (mostly) 2121212, and the reported frequency is
 10M*7/2121212      = 33.000001885Hz
Rarely, (actually 4 out of every 33 captures) it will capture
10M*7/(2121212+1) = 32.99998632Hz, and the average will be 33.0000Hz

The next step possible, the other way is
 10M*7/(2121212-1) = 33.00001744Hz, for a Counter LSB of 0.471ppm

[technix]

If you know the frequency under test (like the 32kHz example you quote)  you can use a simple capture timer, to count cycles.
eg In another thread, it was shown 61 seconds of 32.768kHz resolves to 0.5ppm, and a 16b timer is enough to capture the expected deviations, as you know the MSBs are stable.

For the GPS HAT, it is 32768Hz nominal against 1Hz PPS pulse.
For the color sensor, is is somewhere around 100-600kHz against either a 8MHz ceramic resonator or a 48MHz internal clock PLL'd from said ceramic resonator.

OK, so the DS3231 will not interface with the I2C of the Pi, only providing a PPS signal? Otherwise - you will need to arbitrate accesses between the micro and the Pi to the DS3231, because it only has one control interface.

DS3231 will interface with the Pi over I2C. And I am arbitrating it.

Also, the possibilities to "trim" the TCXO are not very extensive, it seems there is only an "Aging Offset" register that you can use, signed 8 bit value, LSB worth 0.1ppm of change, so at max you can trim +12.7ppm / - 12.8ppm.

I don't need extensive trimming anyway.

Well, just have a look at the register manual. For example, for the PPS sync, you could use e.g. TIM1, configure the counter into free-running auto-reload mode, connect each PPS signal to a TIM1_CHx input and configure the two linked capture/compare stages to capture the counter at each rising edge of the PPS pulse. Then, subtract the two captured counter values. If the result changes, you have a drift and you can use that information to trim the RTC.

Thanks.