*** Warning about switching away from the PLL setting:
When switching away from the PLL setting (%SS = %11), care must be taken to avoid a clock glitch which can hang the P2 chip.
You must switch away from the PLL while preserving the last-written %EDDDDDDMMMMMMMMMMPPPP bits. This means a copy of the last HUBSET clock value should be maintained for this purpose.
If so, and you have a crystal in your system, can you:
1: Switch to PLL mode with %PPPP=%1111
2: Switch away from PLL mode while preserving settings from step 1
3: Switch to the mode you want
?
Chip: you probably know this, but that BASIC ROUND() function you are using implements Bankers Rounding. Is that going to make any subtle gremlins for you?
If so, and you have a crystal in your system, can you:
1: Switch to PLL mode with %PPPP=%1111
2: Switch away from PLL mode while preserving settings from step 1
3: Switch to the mode you want
?
Yes. Here's the sequence I use now:
andn clk_mode, #%11 'clear the two select bits to force RCFAST selection
hubset clk_mode '**IMPORTANT** Switches to RCFAST using known prior mode
mov clk_mode, new_clk_mode 'replace old with new ...
hubset clk_mode 'setup PLL mode for new frequency (still operating at RCFAST)
or clk_mode, #XSEL 'add PLL as the clock source select
waitx ##25_000_000/100 '~10ms (at RCFAST) for PLL to stabilise
hubset clk_mode 'engage! Switch back to newly set PLL
I thought the issue was one of clean clk signal ? (avoiding runt pulses, or clks outside spec)
Thus :
Enable of XTAL clock source too soon (before Osc has reached full amplitude) is to be avoided.
Likewise, switch to PLL before VCO.PLL has settled (locked) is also to be avoided.
IIRC, PLL -> Select RCFAST -> LoadNewPLL Setting -> WaitTime -> Select VCO.PLL is always OK ?
I thought the issue was one of clean clk signal ? (avoiding runt pulses, or clks outside spec)
Thus :
Enable of XTAL clock source too soon (before Osc has reached full amplitude) is to be avoided.
Likewise, switch to PLL before VCO.PLL has settled (locked) is also to be avoided.
IIRC, PLL -> Select RCFAST -> LoadNewPLL Setting -> WaitTime -> Select VCO.PLL is always OK ?
That was the original requirement until the flaw was identified. Now, both that and the PPPP=%1111 glitching has to be handled.
PS: The original sequence could switch to RCFAST and load the new PLL config in the same instruction.
One important point with the "clk_mode" variable, in the above snippet, is it already holds the prior setting value. So first step is use that to switch to RCFAST. Hence the "** IMPORTANT **" comment.
That code is in my gerenal setting routine that I use when doing tests of multiple sys-clock frequencies.
Err, your sequence is not correct. The docs are talking about when PPPP = %1111 is already in use. When PPPP != %1111 then glitch can't happen. I probably should have said no in my first reply.
So steps are:
1: Switch to RCFAST mode with pre-existing PLL config staying the same.
2: Reconfig the PLL mode, discarding settings from step 1 but staying in RCFAST.
3: Wait 10 ms for oscillators to stabilise.
4: Switch to the PLL mode.
The original method is steps 2 to 4, so just step 1 is added for workaround.
If you know you are in RCFAST already, on power up for example, then original method is fine.
What I'm wondering about is the case where you know the system has a crystal installed...
I think in this case, you should be able to switch to another clock setting without knowing the current clock setting by doing this:
1: Switch to PLL mode with %PPPP=%1111 (you are now in a known clock state with no glitch possible because of the %PPPP setting)
2: Switch away from PLL mode while preserving settings from step 1 (switch to, say, rcfast while keeping %PPPP setting)
3: Switch to the mode you want
Assuming the crystal is swinging okay, already, the only thing you need to be careful about is switching away from the PLL when the post divider is set to 1.
Are you saying you can’t switch into that mode without a glitch?
Docs say you just can’t switch out...
Oh, I wasn't trying to understand your idea as an alternate workaround. Right, yes, switching into doesn't glitch and by forcing it to that mode it guarantees you aren't switching away.
And by selecting RCFAST mode in the same config word, it should cover the second criteria of not engaging the PLL for the duration of oscillator settling time too.
ie:
hubset #%1111<<4 | XOSC<<2 'Switches to RCFAST using safe PLL config
hubset new_clk_mode 'setup PLL mode for new frequency (still operating at RCFAST)
or new_clk_mode, #XSEL 'add PLL as the clock source select
waitx ##25_000_000/100 '~10ms (at RCFAST) for PLL to stabilise
hubset new_clk_mode 'engage! Switch back to newly set PLL
EDIT: Shortened the safe config word to minimum needed.
Great! So, this means we don't need to know the current clock setting to safely switch to another, right?
Yep, so far so good. I've now got this as my regular method. All my test programs will now use it.
I wasn't 100% sure you could do this:
hubset #%1111<<4 | XOSC<<2 'Switches to RCFAST using safe PLL config
Good to know.
Same. I had a full length config word with multiplier to above 100 MHz and the enable bit set. Tested with that first. Seemed good so tried it this way as well and still good.
Basic idea is that when switching to the prep'ing RCFAST clock source, also force the PLL mode to PPPP = %1111. This works because changing into that mode doesn't glitch. And it also means it doesn't matter if it already was in that mode since it isn't changing out of it.
Slightly unrelated but is it possible to safely change the PLL operating frequency on the fly while keeping the PLL as the active clock source? ie. change MM...MM, PPPP, DD..DD bit values but maintain SS as 11 in a system that has already been setup following it's usual bootup config. What happens?
> @rogloh said:
> Slightly unrelated but is it possible to safely change the PLL operating frequency on the fly while keeping the PLL as the active clock source? ie. change MM...MM, PPPP, DD..DD bit values but maintain SS as 11 in a system that has already been setup following it's usual bootup config. What happens?
Changing PPPP could cause a glitch. The other two fields could be changed, though. Just beware of frequency overshoot possibly creating too short of a clock pulse and hanging the chip, as a glitch would do.
This isn't mutually exclusive to the two handover options. But I guess it really does supersede them since mailboxing can completely return to original use without the handover requirement. RCFAST handover can stay the default for loaders since it doesn't impose any others.
Video monitors have no issue resync'ing. If you're adjusting the sys-clock then you'll be adjusting the video NCO to match. It would be a good trick to not trip a resync event!
@TonyB_,
In the case of my driver, if you wanted to change the PLL rate while video was running you'd need to re-initialize the video COG with the new timing for the new operating frequency. The driver can't easily re-patch itself on the fly once already up and running, at least the way it is coded at the moment and there's no room to try to add that without taking something else out. Quite a bit of recomputation of COG register parameters is needed, so it is far easier to just restart the COG. The video off time wouldn't last long.
I imagine the same situation applies to other frequency dependent COGs such as USB.
On the other issue with the quoting, I edited a reply to one of Chip's replies and reformatted his quoted section to conform with normal quoting and when I previewed it it looked normal again but I also got a little black popup saying "The quote had to be converted from TextEx to BBCode. Some formatting may have been lost."
Comments
If you switch the %PPPP field to or from value %1111, you could get a glitch. Otherwise, there's no harm.
Docs say this:
If so, and you have a crystal in your system, can you:
1: Switch to PLL mode with %PPPP=%1111
2: Switch away from PLL mode while preserving settings from step 1
3: Switch to the mode you want
?
Thus :
Enable of XTAL clock source too soon (before Osc has reached full amplitude) is to be avoided.
Likewise, switch to PLL before VCO.PLL has settled (locked) is also to be avoided.
IIRC, PLL -> Select RCFAST -> LoadNewPLL Setting -> WaitTime -> Select VCO.PLL is always OK ?
PS: The original sequence could switch to RCFAST and load the new PLL config in the same instruction.
If so, there's no need to know the current clock setting before switching to a new one, right?
That code is in my gerenal setting routine that I use when doing tests of multiple sys-clock frequencies.
So steps are:
1: Switch to RCFAST mode with pre-existing PLL config staying the same.
2: Reconfig the PLL mode, discarding settings from step 1 but staying in RCFAST.
3: Wait 10 ms for oscillators to stabilise.
4: Switch to the PLL mode.
The original method is steps 2 to 4, so just step 1 is added for workaround.
If you know you are in RCFAST already, on power up for example, then original method is fine.
I think in this case, you should be able to switch to another clock setting without knowing the current clock setting by doing this:
1: Switch to PLL mode with %PPPP=%1111 (you are now in a known clock state with no glitch possible because of the %PPPP setting)
2: Switch away from PLL mode while preserving settings from step 1 (switch to, say, rcfast while keeping %PPPP setting)
3: Switch to the mode you want
Is there a reason this won't work?
Docs say you just can’t switch out...
Maybe it’s best to just avoid this mode all together?
And by selecting RCFAST mode in the same config word, it should cover the second criteria of not engaging the PLL for the duration of oscillator settling time too.
ie:
EDIT: Shortened the safe config word to minimum needed.
I wasn't 100% sure you could do this:
Good to know.
Same. I had a full length config word with multiplier to above 100 MHz and the enable bit set. Tested with that first. Seemed good so tried it this way as well and still good.
Basic idea is that when switching to the prep'ing RCFAST clock source, also force the PLL mode to PPPP = %1111. This works because changing into that mode doesn't glitch. And it also means it doesn't matter if it already was in that mode since it isn't changing out of it.
EDIT: Here's my first inclination - https://forums.parallax.com/discussion/comment/1466409/#Comment_1466409
EDIT2: This is it - https://forums.parallax.com/discussion/comment/1466475/#Comment_1466475
Yeah, now I remember. I think I'd miss-read the guidance at the time and figured this idea wouldn't be reliable so stop testing it.
> Slightly unrelated but is it possible to safely change the PLL operating frequency on the fly while keeping the PLL as the active clock source? ie. change MM...MM, PPPP, DD..DD bit values but maintain SS as 11 in a system that has already been setup following it's usual bootup config. What happens?
Changing PPPP could cause a glitch. The other two fields could be changed, though. Just beware of frequency overshoot possibly creating too short of a clock pulse and hanging the chip, as a glitch would do.
> Ok, seems safer to just do it the regular way going back via RCFAST as the intermediate state.
Yes. That way works for sure.
Is this now the agreed, always safe to do when not known for certain, clock switching code?
Any recommendations for this switching if video is running?
Video monitors have no issue resync'ing. If you're adjusting the sys-clock then you'll be adjusting the video NCO to match. It would be a good trick to not trip a resync event!
In the case of my driver, if you wanted to change the PLL rate while video was running you'd need to re-initialize the video COG with the new timing for the new operating frequency. The driver can't easily re-patch itself on the fly once already up and running, at least the way it is coded at the moment and there's no room to try to add that without taking something else out. Quite a bit of recomputation of COG register parameters is needed, so it is far easier to just restart the COG. The video off time wouldn't last long.
I imagine the same situation applies to other frequency dependent COGs such as USB.
Looks to be fixed for now !
On the other issue with the quoting, I edited a reply to one of Chip's replies and reformatted his quoted section to conform with normal quoting and when I previewed it it looked normal again but I also got a little black popup saying "The quote had to be converted from TextEx to BBCode. Some formatting may have been lost."