STM32G0B1RE Using a timer to sample a clock signal

[undacmic]

Hello and thank you for taking the time to read and answer my question.

 

What I want to do:

I have SYSCLK configured at a frequency of 16 MHz (using HSI), and a PLL block clock with a frequency of 18 MHz.

I want to sample the PLL clock on the rising edge of the SYSCLK. (the application in which I want to use this is not really of interest in this post).

What is the most efficient way to do this?

Use a timer channel in input capture mode for the reference clock and read the value of the other channel where I connect the 18 MHz clock, whenever I have a rising edge?

Interrupts? (It seems like 16.000.000 interrupts a second might saturate the CPU)

Any other good way?

[Javier1]

Im not sure i fully grasp yopur needs, but what about DMA+ADC, using timer base without interruption? disabling DMA interruption aswell?, just thinkign outloud here.

The ADCs are supposed to be able to manage up to 64Mhz.

Did you already tried something?

[Carl_G]

---

@Javier1 wrote:

...

The ADCs are supposed to be able to manage up to 64Mhz.
..

---

The adc can be run faster but the sampling time still has its limits.

[undacmic]

---

@Carl_G wrote:

---

@Javier1 wrote:

...

The ADCs are supposed to be able to manage up to 64Mhz.
..

---

The adc can be run faster but the sampling time still has its limits.

---

Interesting, giving the fact I only need to know if the current clock pulse value is either a logic 1 or a 0, I don't mind truncating the resolution at all, 6 bits is more than enough, but it still seems I'm using a bit much.

Can't GPIO support 16MHz access to the input of the pin and just configure a timer with the frequency of the reference 16 MHz clock to generate a gpio read on each rising edge event?

[waclawek.jan]

What is "PLL block"? Some external circuitry?

JW

[undacmic]

No, when I say PLL block I'm referring to the three clocks (PLLRCLK, PLLQCLK and PLLPCLK) which can be generated internally, the phased locked loop clocks.

[Carl_G]

If all you need is a 1 or a 0 then what you want is called Input Capture. I reread your post. I think you are maybe using some terms wrong or misunderstanding something.

If you want to measure the signal on a certain GPIO using an input capture timer that is running on the PLL that's totally doable. However, according to the Nyquist theory you want your sampling clock to be at least twice as fast as your sampled clock. So if your input signal is 18MHz then you should run your sampling clock of your timer at least 36MHz. Are you trying to measure frequency, or duty cycle or pulse width? Techniques will depend on which.

[undacmic]

Okey, let's start from the premise I am wrong.

Right my sampling clock doesn't comply with Nyquist theorem, but I don't want to digitally reproduce the 18 MHz analogic signal.

I am merely trying to poll it's current logic value, not the frequency, nor the duty cycle or the pulse width. I don't get how Nyquist theorem affects me here.

[Carl_G]

---

@undacmic wrote:

Okey, let's start from the premise I am wrong.

Right my sampling clock doesn't comply with Nyquist theorem, but I don't want to digitally reproduce the 18 MHz analogic signal.

I am merely trying to poll it's current logic value, not the frequency, nor the duty cycle or the pulse width. I don't get how Nyquist theorem affects me here.

---

It's because you have presented an incomplete problem. You are saying you want to sample a signal but you aren't really saying what quality if the signal you are interested in. If Nyquist doesn't apply then fundamentally you're saying it doesn't matter what frequency that signal is. Its hard for me to imagine a scenario where that is true. It's highly unusual to present a signal, specify its frequency, then insist the frequency doesn't matter.

Seems like there is a language or term barrier here. And also maybe some engineering inexperience. I think you should run with what you have. When you run into issues then you can come back and with more detail try to understand what you have to deal with. Of course, sometimes you have to be lucky enough to hit the problem sooner rather than later. I appreciate that you are filtering out lots of the information that you feel isn't relevant and saving us from having to read through all of that. And maybe there are some proprietary elements. Nevertheless, its hard to do that when you don't fully understand the principles.

[waclawek.jan]

My understanding of the initial post is, that the intention is to clock timer using 16MHz sysclk while somehow characterize a 18MHz signal, whatever is it's source, and in whatever way is it routed to the timer (which remains to be a question - connecting TIMx_CHx to MCO externally, perhaps?)

While this most probably won't result in anything reasonable, the question is: why? The final target may or may not be within reach, but if yes, most probably not in the proposed way.

JW

[undacmic]

This is my setup:

HSI16 to MCO and connected externally to a GPIO pin.

PLLQCLK of 18 MHz to MCO2 and connected externally to TIM16_CH1.

Configured TIM16 in input capture mode, generate an interrupt on capture event and poll the GPIOx IDR register for its value.

Why now:

I made two other posts in my attempt to reproduce a small random number generator. Again, it's just an attempt.

What I'm trying to base my attempt on is the intrinsic time jitter the PLL clock has (which I measured as well using an oscilloscope). Sampling the PLL clock with a specific frequency I choose (16MHz) is another attempt at reproducing the research I found here: True Random Number Generator Embedded in Reconfigurable Hardware 

[KnarfB]

If you can live with SYSCLK/2, try SPI.

hth

KnarfB

[waclawek.jan]

If instead of STM32G0B1 you take STM32G0C1, it has a built-in RNG.

JW