ESP32 RTC clock instability with external XTAL or oscillator
Posted: Fri Apr 29, 2022 2:59 pm
Hi, I've encountered some problems trying to get the RTC clock to use an external XTAL or oscillator on an ESP32.
The problem
From what I've read older revisions of the silicon (before rev 3) have problems driving a XTAL.
The problem is when the ESP detects the XTAL, but when it goes into deep sleep, it doesn't actually clock from it.
There's no way to wake it up as the ULP program is what's supposed to wake the main CPU.
There's workarounds in the IDF menuconfig options but those disable the use of ULP processor and that's not an option for the project.
Which is why the team and I looked at external oscillators.
Unfortunately I've seen similar instabilities with them as well.
However there's conflicting information about what the input to the ESP should be.
Hardware Design IDF menuconfig options
The TCXO output is a square wave from 0 to 3.3V
When connecting it directly to the 32K_XN the ESP showed the exact same problem as with some of the XTALs.
"Solutions"
So far we've managed to find 2 circuits that seem to "work" but they were made in the air and there's no guarantee we won't face any problems when production comes.
In both cases we assumed what was written in the IDF comments to be "more correct" than what was in the Hardware Design as it was what "worked"
Resistor divider This circuit seems to work but when observed at the ESP32 pin the impulses become triangles with a small amplitude and the fear is that in some conditions (e.g. drastic temperature change) the ESP will stop clocking from it.
Capacitor decoupler This circuit also seems to work and somewhat preserves the TCXO output waveform.
However when measured at the ESP32 pin the signal is still a square wave but from 0.5V to 1.5V.
This amplitude seems at the very top of the operational range (assuming IDF comments) and we don't know how much wiggle room we have when it comes to production.
Questions
The problem
From what I've read older revisions of the silicon (before rev 3) have problems driving a XTAL.
The problem is when the ESP detects the XTAL, but when it goes into deep sleep, it doesn't actually clock from it.
There's no way to wake it up as the ULP program is what's supposed to wake the main CPU.
There's workarounds in the IDF menuconfig options but those disable the use of ULP processor and that's not an option for the project.
Which is why the team and I looked at external oscillators.
Unfortunately I've seen similar instabilities with them as well.
However there's conflicting information about what the input to the ESP should be.
Hardware Design IDF menuconfig options
Code: Select all
"External 32kHz oscillator" allows using 32kHz clock generated by an external circuit.
In this case, external clock signal must be connected to 32K_XN pin.
Amplitude should be <1.2V in case of sine wave signal,
and <1V in case of square wave signal.
Common mode voltage should be 0.1 < Vcm < 0.5Vamp, where Vamp is the signal amplitude.
Additionally, 1nF capacitor must be connected between 32K_XP pin and ground.
32K_XP pin can not be used as a GPIO in this case.
When connecting it directly to the 32K_XN the ESP showed the exact same problem as with some of the XTALs.
"Solutions"
So far we've managed to find 2 circuits that seem to "work" but they were made in the air and there's no guarantee we won't face any problems when production comes.
In both cases we assumed what was written in the IDF comments to be "more correct" than what was in the Hardware Design as it was what "worked"
Resistor divider This circuit seems to work but when observed at the ESP32 pin the impulses become triangles with a small amplitude and the fear is that in some conditions (e.g. drastic temperature change) the ESP will stop clocking from it.
Capacitor decoupler This circuit also seems to work and somewhat preserves the TCXO output waveform.
However when measured at the ESP32 pin the signal is still a square wave but from 0.5V to 1.5V.
This amplitude seems at the very top of the operational range (assuming IDF comments) and we don't know how much wiggle room we have when it comes to production.
Questions
- Should we follow the Hardware Design or the IDF comments?
- Which circuit is more reliable or do you have one that has never had any problems?