I don't know if this question is just too involved/obscure but thought I might give it a go...
I have a ATSAMC21J where pin 20 PA11 is intended as an external clock input which I will subsequently measure...
I have pin 20 configured as Mux H i.e. GCLK_IO[5]
I then have GCLK5 Generator configured as having GCLK_IN[5] as it's source with a divide by 1.
When I have this configuration my Harmony 3 based app just gets stuck at...
static void GCLK5_Initialize(void)
{
GCLK_REGS->GCLK_GENCTRL[5] = GCLK_GENCTRL_DIV(1UL) | GCLK_GENCTRL_SRC(1UL) | GCLK_GENCTRL_GENEN_Msk;
while((GCLK_REGS->GCLK_SYNCBUSY & GCLK_SYNCBUSY_GENCTRL5_Msk) == GCLK_SYNCBUSY_GENCTRL5_Msk)
{
/* wait for the Generator 5 synchronization */
}
}
It gets stuck waiting for GCLK_SYNCBUSY_GENCTRL5_Msk to clear.
Now reading the datasheet...
"This bit is cleared when the synchronization of the Generator Control n register (GENCTRLn) between clock domains
is complete, or when clock switching operation is complete."
which doesn't tell me very much!
Now the device is currently NOT connected to an external source and hence pin 20 (PA11) is currently floating.
Does this require a transition on the pin to get the synchronisation to complete? (If so, that's a bit rubbish!)
Yes, you do need a few edges for the synchronization to complete. You need both clocks for the synchronization, that's how it works.
In some cases you can just remove the waiting, the register write would be suck, but it should not affect anything else. It will synchronize when the clock appears.
I grounded the pin and it continued so that's pretty conclusive. Harmony doesn't like this so I will have to switch source later but that's OK.
I take your point regarding the synchronisation, I'll factor that in.
Thanks!
But keep in mid that if you plan on this clock disappearing arbitrarily, you are likely to have a lot more synchronization issues with the peripherals that actually use that clock.
What is your final goal for this?
What is your final goal for this?
It's an external signal that I need to measure its FREQ(M)uency. Being absent is a possible state. Expect it to be around 2MHz
It's an external signal that I need to measure its FREQ(M)uency. Being absent is a possible state. Expect it to be around 2MHz
In that case use TCC capture input.
Using GCLK for this is not correct. GCLK is designed for clocking. You will have a lot of issues doing it that way, since it expects stable glictch-free clock. This signal is used directly for clocking, so you are responsible for ensuring that this clock is clean.
And FREQM itself will lock if one of the clocks is missing too.
Using GCLK for this is not correct. GCLK is designed for clocking.
They have the two inputs to FREQM (ref/msr) specifically coming from GCLKIO, so hard to see how this is not correct as there is no other way to use it.
And FREQM itself will lock if one of the clocks is missing too.
I don't have a samc21 so just asking (have a samd10, no freqm)- but that seems odd. Are not the two gclkio clocks each simply clocking an async counter? If you lose the msr clock, I would think you simply get a 0 value when the measurement completes, and if you lose the ref clock then freqm remains busy/not done so would require a swrst.
They have the two inputs to FREQM (ref/msr) specifically coming from GCLKIO, so hard to see how this is not correct as there is no other way to use it.
It is not correct to use it for unstable inputs. I really have no idea what was the though behind FREQM, I have never seen it used for anything useful in practice. It might be useful to automatically detect supplied clock frequency or something like this, but I don't know how you would use that in practice.
But if you want to do typical frequency or duty cycle measurement, then use a timer, just like for any other MCU.
If you lose the msr clock, I would think you simply get a 0
You will most likely get last synchronized value.
value when the measurement completes, and if you lose the ref clock then freqm remains busy/not done so would require a swrst.
SWRST would not complete without both clocks.
Having both clocks is an explicit requirement: "Each of the generic clocks (GCLK_FREQM_REF and GCLK_FREQM_MSR) must be configured and enabled."
Hm. Well firstly this approach works well in the presence of an external clock; I have been using it for ages and the results look good.
Secondly, this is a problem in the absence of a signal but this is easily detectable via SYNCBUSY
I now use a different known clock as source until I need it and then attempt a switch and observe SYNCBUSY. That keeps Harmony happy.
FREQM suits my use case very well even though that's not necessarily why I chose the device.