ESP32-S3 GPIO 33 to GPIO 37 reserved for OPI mode (IDFGH-14046)

[HamitAkay]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.3.1

Espressif SoC revision.

ESP32-S3 (QFN56) (revision v0.2)

Operating System used.

Windows

How did you build your project?

VS Code IDE

If you are using Windows, please specify command line type.

CMD

Development Kit.

WT32-SC01 Plus

Power Supply used.

USB

What is the expected behavior?

GPIOs 35, 36, and 37 are available and connected to the I2S audio amplifier on the development board

What is the actual behavior?

I get the following warnings that the pins are not usable
W (298) i2s_common: GPIO 37 is not usable, maybe conflict with others
W (308) i2s_common: GPIO 35 is not usable, maybe conflict with others
W (308) i2s_common: GPIO 36 is not usable, maybe conflict with others

Steps to reproduce.

1. Use the example standard I2S project on a ESP32-S3-N16R2 module
2. Adjust the pin numbers as: bclk = GPIO_NUM_36, ws = GPIO_NUM_35, dout = GPIO_NUM_37
3. Compile and flash the project

Debug Logs.

W (298) i2s_common: GPIO 37 is not usable, maybe conflict with others
W (308) i2s_common: GPIO 35 is not usable, maybe conflict with others
W (308) i2s_common: GPIO 36 is not usable, maybe conflict with others

More Information.

I tried the same board with an Arduino IDE example, and the I2S is working fine and I can play music.

[Icarus113]

N16R2 is with Quad Flash and Quad PSRAM, whereas the IO35 36 37 are used for Octal Flash.

Could you help check this reserve_pin_mask value that are used here?

[HamitAkay]

The reserve_pin_mask value comes from esp_mspi_io_t enum. The enum will have IO33 through IO37 included in it if SOC_SPI_MEM_SUPPORT_OPI_MODE is defined, which is the case for an ESP32-S3 chip regardless of its Flash or PSRAM configuration.

[suda-morris]

it's like the issue was fixed on the master branch, but not backport yet: a80603c

@L-KAYA