Some pins cannot be used as SPI ChipSelect as they block/disable the MISO pin (GPIO19)?

Board

Custom PCB with ESP32-WROOM V3 ufl 16MB

Device Description

custom board

Hardware Configuration

SPI (Mosi 23, Miso 19, Clk 18) pins are connected to -Ethernet (CS 32) -MCP23S17 (CS 33) -SC16IS750 (CS 15) -second SC16IS750 (tried CS 2, 3, 4, 5 and 12 but all not working) -....

Version

v3.3.7

Type

Bug

IDE Name

VSCode

Operating System

win11

Flash frequency

40

PSRAM enabled

yes

Upload speed

115200

Description

(We use platform = https://github.com/pioarduino/platform-espressif32/releases/download/55.03.37/platform-espressif32.zip) Also tested with platform = espressif32, same result

The issue is that it seems that at least GPIO 2,3,4,5 and 12 cannot be used as SPI ChipSelect pin. I tried to use these for the second SC16IS750 but did not get it to work. When I physically switch the GPIO15 the second SC16IS750 works. (I do not have any other GPIO's available)

There is a ping functionality in the SC16IS750 library which writes 0x55 to a register via SPI and reads it back. For all pins I see this happening on the scope, both MOSI and MISO signals look the same (and show the 0x55 being sent or returned) as when it functions normally (with GPIO15 as CS)

But somehow the ESP is not receiving/parsing the signal on the MISO line...?

Been working on this with Claude/Gemini and tried several things but not resolved, this was determined:

Potential Root Causes for GitHub Investigation

SPI Peripheral Peripheral/IOMUX Clash: GPIO 2, 4, 5, and 12 are native HSPI (SPI2) pins. 
Toggling them while the VSPI (SPI3) peripheral is actively being driven by high-speed 
concurrent drivers (like Ethernet) may trigger internal hardware-level bus arbitrage in the IOMUX, 
inadvertently disconnecting/inhibiting the internal VSPI MISO (GPIO19) input path to the CPU.

Peripheral Driver Reconfiguration/Masking: The Arduino ESP32 core might perform implicit 
pin-mapping or automatic pinMode register overrides for low-number pins (GPIO < 16) during
 SPI.beginTransaction() or concurrent background transfers, causing timing desynchronization
 or disabling the input buffer on GPIO19 specifically when those low pins are toggled.

Internal Resource Conflict with UART0/Flash (GPIO3/GPIO2): Even when Serial or flash configs 
are explicitly remapped or passed GPIO_NUM_NC (-1), low-level ROM-bootloader hooks or 
peripheral manager locks might fail to fully decouple the internal input/output structures of 
these specific pins, resulting in an internal loopback or override that drops parallel VSPI RX bytes.

Any insights/suggestions on this?

Sketch

it is a very large project....

Debug Message

I serial print the data read via SPI and see 0x55 when GPIO15 is used as CS, When one of the other pins is used I see 0x00

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.