26MHz TCXO (not crystal) -- which pin to connect to?

[hassan789]

Hi ESP team.
I am planning on using a digital 26MHz TCXO instead of a crystal. The signal output by this will be a square wave.

1. Is it ok to use a 1.8v digital 26MHz square-wave signal?
2. Which pin would I route that to? XTAL_N or XTAL_P

The reason I prefer to use the 26MHz is because it has a much better ppm tolerance, and also I need to route a clock to multiple chips. This is easy to do with an TCXO, but to do this with a crystal would be difficult, as it would need to be tuned, and would have to make sure there is not too much board pF and resistance.

Thanks

[ZaneKaminski]

I would also like to connect a 40 MHz clock generated elsewhere in my system to the ESP32.

Hassan789, I think a 1.8V signal would probably be too low. It's likely a 3.3V level.

Anyway, it's difficult to say whether it should be connected to XTAL_N or XTAL_P. Other chip vendors use a naming convention like "XTAL_IN"/"XTAL_OUT", which clarifies it.

Can anyone say whether this configuration is (or will be) supported, and what to do with XTAL_N and XTAL_P?

[ESP_Angus]

Hi folks,

Sorry for the slow reply on this one, I wanted to confirm some details with the hardware team:

• Using an external oscillator for a clock input will work, provided it meets stability requirements.
• Connect the external clock input to the XTAL_P pin. (This information is actually on page 9 of the datasheet, in the pin descriptions table.)
• 1.8V square wave should be sufficient.
• 40MHz will be OK but 26MHz may be a problem if you need WiFi. See the discussion here and software change here.

[hassan789]

Thanks for confirming ESP_Angus!

[novalight]

• Connect the external clock input to the XTAL_P pin. (This information is actually on page 9 of the datasheet, in the pin descriptions table.)

Thanks for the info Angus! I have one question left though: I guess, when you use a crystal, the ESP32 does not allways oscillate this crystal to save power (Deep-Sleep etc.). Most TCXOs have an active-high enable-pin. Two questions on that:

• Would it be a problem if the oscillator runs all the time? (When power consumption won't matter)
• If we want the osc to power down like the ESP32 would do it with the crystal: how can we obtain an "oscillator-enable" signal from the ESP32? Probably using the XTAL_N + Diode + RC-Network?

Thanks for any hint on that issue!

[novalight]

Sorry for pushing this, but since we have to plan our next board revision, some additional hints would be quite helpful here.

• Would it be a problem if the oscillator runs all the time? [note: also during reboot, deep sleep, etc.] (When power consumption won't matter)
• If we want the osc to power down like the ESP32 would do it with the crystal: how can we obtain an "oscillator-enable" signal from the ESP32? Probably using the XTAL_N + Diode + RC-Network? [note: what would be the 'native' way of generating the enable signal]

[ESP_Angus]

Hi,

Sorry for the long silence on this issue.

[*] Would it be a problem if the oscillator runs all the time? (When power consumption won't matter)

No, aside from the oscillator's own power consumption this should not be an issue for the ESP32.

[*] If we want the osc to power down like the ESP32 would do it with the crystal: how can we obtain an "oscillator-enable" signal from the ESP32? Probably using the XTAL_N + Diode + RC-Network?[/list]

This is for deep sleep mode, yes? Because otherwise you can probably use the ESP32's EN pin as the XTAL EN as well.

For deep sleep, I think that XTAL_N plus some external circuitry is an option.

However, there is also apparently an undocumented test function on touch pad 6 (GPIO14) which can be used to mux the oscillator enable signal to an external pin. The code to access this is something like:

Code: Select all

#include "soc/rtc_io_struct.h"
#include "driver/rtc_io.h"

RTCIO.touch_pad[6].mux_sel = 1;
RTCIO.touch_pad[6].fun_sel = 3; /* undocumented osc_en signal mux mode */
rtc_gpio_set_direction(TOUCH_PAD_NUM6_GPIO_NUM, RTC_GPIO_MODE_DISABLED);
rtc_gpio_pulldown_dis(TOUCH_PAD_NUM6_GPIO_NUM);
rtc_gpio_pullup_dis(TOUCH_PAD_NUM6_GPIO_NUM);

...

esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_ON);
esp_deep_sleep(1000 * 1000);

I've tested this on a logic analyzer and it seems like a useful signal, but I don't have a board with an external TCXO to verify that everything works as expected - please test it yourselves before committing to it for a design.

You'll also need a pullup on GPIO14. The pullup should allow the oscillator to start on the initial power-on, and from then on the RTC I/O domain (which isn't dependent on the XTAL signal) will control it as the board goes in & out of deep sleep.

As this is an internal test mode it may not be present in future chips after the ESP32.

[novalight]

Angus, thanks for the information so far! We implemented now the 40 MHz TCXO on our prototype. It is always on (since it's not a battery powered application). For 32k we still use a simple 10 ppm external crystal. Everything is running fine so far.

One additional question though: With the ECS-TXO-2520 we have 2.5 ppm from -40C to 80C. Will the RTC and internal oscillators be calibrated against that very stable reference as temperature drifts? Are the PLLs locked to the external oscillator? Or in short: does using a TCXO imply I don't have to worry about frequency deviations regarding temperature anymore?

[hassan789]

does using a TCXO imply I don't have to worry about frequency deviations regarding temperature anymore?

correct

[ESP_Angus]

One additional question though: With the ECS-TXO-2520 we have 2.5 ppm from -40C to 80C. Will the RTC and internal oscillators be calibrated against that very stable reference as temperature drifts? Are the PLLs locked to the external oscillator? Or in short: does using a TCXO imply I don't have to worry about frequency deviations regarding temperature anymore?

Everything but the RTC slow clock, which is used for some RTC internal peripherals, can/will be sourced from the "XTAL CLK" (ie your 2.5ppm TCXO).

This includes the APB peripheral bus clock, so all the "digital" peripherals like SPI, UART, I2S, high resolution timers, etc, etc. The PLLs are also fed from here. All clock sources used for WiFi/Bluetooth are fed from here.

The RTC slow clock (and optionally the RTC fast clock) are sourced from a "Slow" clock source, in this case your 32kHz Crystal (if configured in menuconfig). These are used for some "RTC domain" analog functions, but generally not for ones where clock drift will be a problem.

The ESP32 Technical Reference Manual chapter "Reset and Clock" has more details about ESP32 clock distribution.