ESP32 Forum

Hi,
I was unable to confidently derive from (the schematics in) the documentation if there is a 32kHz crystal attached to the RTC GPIO pins 32 and 33 of the ESP32 DevkitC V4. In earlier versions of the Wroom datasheet (ESP-WROOM-03 Specifications, Version 1.0, 2015.12) there is one depicted but not in the current version. Can you please clarify in which models there is (n)one?

The reason why I was investigating this question at all was because I was trying to use the pins as GPIOs and noticed very erratic behavior (exceptions, reboot loops etc) when doing so. Eventually I came to the conclusion that the RTC GPIO pins have to be switched to general general purpose pins (thanks to some bits in the forum). To use them I had to configure them normally with gpio_config() but additionally change their functionality with rtc_gpio_deinit(). As far as I can tell this changes bits 17 and 18 of RTCIO_XTAL_32K_PAD_REG to 0. However, according to the datasheet this is the reset value (Register 4.52 in the ESP32 Technical Reference Manual, Version 2.9). So I conclude that something in the firmware generated by the IDF enables the RTC muxing before my application starts. This seems to be a bug to me if the RTC functionality cannot/is not used anyway on my hardware and should be more clearly documented as it was very surprising. What is responsible for the RTC functionality to be enabled by default?

Hi stefanct,

stefanct wrote:Can you please clarify in which models there is (n)one?

DevKitC board (all versions of them) come with ESP-WROOM32 module, not ESP-WROOM03. None of the versions of ESP-WROOM32 came with a 32k XTAL. DevKitC boards don't come with 32k XTAL installed either.

stefanct wrote:As far as I can tell this changes bits 17 and 18 of RTCIO_XTAL_32K_PAD_REG to 0. However, according to the datasheet this is the reset value (Register 4.52 in the ESP32 Technical Reference Manual, Version 2.9).

With default settings in sdkconfig file, RTCIO_XTAL_32K_PAD_REG is set to 0x84100010 at application startup (app_main), so both these bits are 0. If you add a line

printf("RTC_IO_XTAL_32K_PAD_REG=0x%08x\n", REG_READ(RTC_IO_XTAL_32K_PAD_REG));

near the top of app_main, (and also include "soc/rtc_io_reg.h"), do you see a different value?
(Note that a long time ago, before IDF version 2.0-rc1, some startup code indeed initialized GPIOs 32 and 33 as RTC IOs. As far as I can tell, this is no longer the case.)

ESP_igrr wrote:

stefanct wrote:Can you please clarify in which models there is (n)one?

DevKitC board (all versions of them) come with ESP-WROOM32 module, not ESP-WROOM03. None of the versions of ESP-WROOM32 came with a 32k XTAL. DevKitC boards don't come with 32k XTAL installed either.

Oh, I was not aware that "03" was a model name. Everything's clear now. Sorry.

ESP_igrr wrote:

stefanct wrote:As far as I can tell this changes bits 17 and 18 of RTCIO_XTAL_32K_PAD_REG to 0. However, according to the datasheet this is the reset value (Register 4.52 in the ESP32 Technical Reference Manual, Version 2.9).

With default settings in sdkconfig file, RTCIO_XTAL_32K_PAD_REG is set to 0x84100010 at application startup (app_main), so both these bits are 0. If you add a line

printf("RTC_IO_XTAL_32K_PAD_REG=0x%08x\n", REG_READ(RTC_IO_XTAL_32K_PAD_REG));

near the top of app_main, (and also include "soc/rtc_io_reg.h"), do you see a different value?
(Note that a long time ago, before IDF version 2.0-rc1, some startup code indeed initialized GPIOs 32 and 33 as RTC IOs. As far as I can tell, this is no longer the case.)

Interesting. I do indeed now get the same readout before and after calling rtc_gpio_deinit() (RTC_IO_XTAL_32K_PAD_REG=0x84100010) but I have updated IDF in the meantime unfortunately because I was relatively sure about it - but did not actually check the register values. But the update was only from the state of the master branch on github about a month ago to the current HEAD version. I'll try to investigate and reproduce the problem. Thanks for your insights so far!