GPIO32 and GPIO33 on DevkitC V4 (Wroom)

[stefanct]

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?

[igrr]

Hi stefanct,

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.

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.)

[stefanct]

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.

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!