[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.
IDF version.
v5.2.1
Espressif SoC revision.
ESP32-D0WDQ6 (revision v1.0)
Operating System used.
macOS
How did you build your project?
CLion IDE
If you are using Windows, please specify command line type.
None
Development Kit.
Dev Kit with ESP32-WROOM-32
Power Supply used.
USB
What is the expected behavior?
According to the Technical Reference Manual (5.1), the GPIO27 pin should be reset state '0', meaning 'input disabled'.
Information retrieved from page 60 'Table 43. IO_MUX Pad Summary'
What is the actual behavior?
If I dump the GPIO configuration of the GPIO27 pin, right at the beginning, the dump shows, that the input is enabled. This incorrect behavior only appears on GPIO27.
As we explained in your other issue, you shouldn't be relying on the default values that were documented in the TRM. We will add a note to the programming guide to let the users aware of it.
Answers checklist.
IDF version.
v5.2.1
Espressif SoC revision.
ESP32-D0WDQ6 (revision v1.0)
Operating System used.
macOS
How did you build your project?
CLion IDE
If you are using Windows, please specify command line type.
None
Development Kit.
Dev Kit with ESP32-WROOM-32
Power Supply used.
USB
What is the expected behavior?
According to the Technical Reference Manual (5.1), the GPIO27 pin should be reset state '0', meaning 'input disabled'.
Information retrieved from page 60 'Table 43. IO_MUX Pad Summary'
What is the actual behavior?
If I dump the GPIO configuration of the GPIO27 pin, right at the beginning, the dump shows, that the input is enabled. This incorrect behavior only appears on GPIO27.
Steps to reproduce.
Code 1 (ESP-IDF GPIO):
Code 2 (Directly reading the register):
Debug Logs.
Code 2: