2020-06-24 04:06 AM
Trying to generate a 512 Hz signal that is synchronous to the LSE.
MCU is an STM32L476ZETx.
Measuring the signal on RTC_OUT_CALIB with a Keysight tabletop multimeter. (And also with an oscilloscope.)
Observation:
Setting "RTC_CALIBOUTPUT_1HZ": measured frequency = 999.99 mHz
Setting "RTC_CALIBOUTPUT_512HZ": measured frequency = 496.5x Hz (jittery)
Why is it that the nominally "512 Hz" signal is way out, whereas the 1 Hz is as perfect as can be expected?
My expectation was that the 512 Hz are derived from the same clock and are therefore equally precise. We were planning to use this 512 Hz signal as a common clock for various external peripherals.
I am not entirely convinced that PCB layout has anything to do with this issue, since the 1 Hz signal appears to be working just fine. Happy to be proven wrong, though...
Similar observations seem to have been made by others in the past - with no solutions on file so far:
2020-06-24 05:49 AM
Please have a look into RM0351, chapter 38.3.15 (currently page 1240):
"The RTC_CALIB duty cycle is irregular: there is a light jitter on falling edges. It is therefore recommended to use rising edges."
Please also check how the frequency measurement has been performed: triggered with falling or rising edges?
/Peter
2020-06-24 07:17 AM
Peter, thanks for the quick reply. I was indeed aware of the statement about jittery falling edges - but thanks for pointing this out again, it is a useful bit of information that was missing from my original post.
I attach a scope snapshot of the 512 Hz signal with "persistence" enabled. Triggered on the blue diamond in the center. As you can see, the farther out you go, the more the edges (both rising and falling) show these as yet unexplained deviations.
Could the output signal be affected by any other activity/peripheral/interrupt? If that were the case, how come this doesn't equally affect the 1 Hz signal?
2020-06-24 09:00 AM
Any coupling of RTC OUT to the Oscillator pins?
2020-06-25 01:35 AM
I was secretly hoping for a reply along the lines of "This is a known issue with STM32L476ZETx chips and will be fixed in the next silicon revision."
But a coupling issue is beginning to look likely, I guess.
Not entirely sure how to prove/disprove this hypothesis :(
2020-06-25 06:11 AM
One more observation: With RTC_OUT_CALIB set to RTC_CALIBOUTPUT_512HZ, I cycled the "LSE Drive Capability" setting through all 4 possible values, and measured the frequency of the resulting signal for each setting:
| LSE_Drive_Capability | f (512_Hz_Calib_out) |
|-----------------------|----------------------|
| low | 496.0 Hz |
| medium low | 508.1 Hz |
| medium high | 524.3 Hz |
| high | 525.2 Hz |
So I guess this indicates that some sort of coupling is going on between RTC_OUT and the Oscillator in my design. Otherwise the measured frequency should be independent of the "drive capability" (and equal to 512.0 Hz in all cases). Any further comments much appreciated of course, but I suspect there is nothing I can do to fix this issue in software.
2020-06-25 06:50 AM
Yet another update: Routing the RTC_CALIBOUTPUT_512HZ signal to its alternate pin (PB2), I get a perfect 512.0 Hz square wave. PB2 is located on a different edge of the package - I guess now I know, why! :)
2020-06-25 11:16 AM
What was the original pin? Were there any differences in its settings, e.g. OSPEEDR, PUPDR? Is this a "known good" board or is it your own? What is the power supply arrangement?
JW
2020-06-25 11:07 PM
Original pin was PC13 (7), right next to PC14=RCC_OSC32_IN.
Alternate pin is PB2 (48).
My understanding is that OSPEEDR, PUPDR, etc for PC13 are not modifiable once the pin is configured as "Calibration Out", as this pin is/becomes part of the "low power RTC" subsystem (my wording).
The settings for the alternate pin (PB2) are modifiable. I had them set to their default values (no pull-up/pull-down, low speed).
The board is our own, i.e. "known bad".
2020-06-26 02:48 PM
Thanks for the info. Interesting.
> Original pin was PC13 (7), right next to PC14=RCC_OSC32_IN.
Ah I see, so it's one of the backup-domain-related pins.
> [...] not modifiable [...] this pin is/becomes part of the "low power RTC" subsystem
Sounds plausible.
Thanks again.
JW