2018-01-17 04:13 PM
Again, a question/request to ST:
PLL output dividers' desctiptions contain this warning:
These bits should be written only if PLL is disabled.
Is there any deeper underlying reason for this, or is this only to prevent transient functional irregularities in attached peripherals due to gliches on clock (i.e pulses shorter than any of the old and new halfperiod) during the switching?
In other words, if there's no active peripheral attached to given clock, may it be safe to switch it on the fly? Or will that result in the PLL/whole chip grinding to halt and catch fire?
The particular reason why I'm asking is, that in STM32F446, if SPDIF-Rx is clocked from PLL_R, after detecting the incoming SPDIF stream's speed (at maximum required clock), if the incoming stream is slow, the clock could be throttled back to reduce consumption and EMI. SPDIF-Rx itself does not have a clock divider; and it does not need to be active at the moment of speed switching, but PLL itself can't be switched off if used also as a primary clock source to the rest of the chip.
But there may be other scenarios where relaxing the above requirement to 'don't change these bits while there's an active peripheral connected to this output' may be beneficial, so if there's no particular reason to be strict, please consider this change.
And please comment.
JW
2018-01-17 05:40 PM
One might hope that P, Q and R are totally independent of the VCO/PLL settings, and that a) the register is not locked read-only while running and b) that writing doesn't reset hidden counters or have other side-effects. The write to the register might be asynchronous to the 192-432 MHz VCO
I don't think the counters/dividers are wide enough for it to go totally out to lunch when the constants are changed. But I also don't think any effort was made to allow changes to be made cleanly/safely, that was all moved to the clock source selection, where you select a source, and wait for it switch gears without any unduly short mark or space times.
2018-01-18 02:12 AM
Yes this is exactly what I am thinking. I duly tested a) on PLL_R and it worked as expected. b) can't be tested without ST or heavy reverse-engineering stuff at hand... ;)
What I am seeking is blessing from ST.
JW