spi_bus_add_device() unconfigures RMT pin in esp-idf 5.4

[RafaelGD]

Hello, my project configures an RMT pin and then I initialize an SPI device with miso, mosi, slck and cs being different pins from the RMT, but when calling spi_bus_add_device() the rmt pin is unconfigured, this only happens in esp-idf 5.4, esp-idf 5.3.1 does not exhibit this behavior, any idea why this happens? My spi bus configuration below:

spi_bus_config_t buscfg = {
.mosi_io_num = pSPIConfiguration->xPinMOSI,
.miso_io_num = pSPIConfiguration->xPinMISO,
.sclk_io_num = pSPIConfiguration->xPinSCLK,
.quadwp_io_num = pSPIConfiguration->bSPIMultiIOMode ? pSPIConfiguration->xPinWP : -1,
.quadhd_io_num = pSPIConfiguration->bSPIMultiIOMode ? pSPIConfiguration->xPinHD : -1,
.data4_io_num = -1,
.data5_io_num = -1,
.data6_io_num = -1,
.data7_io_num = -1,
.max_transfer_sz = pSPIConfiguration->u32MaxTransSize,
.flags = SPICOMMON_BUSFLAG_MASTER | SPICOMMON_BUSFLAG_GPIO_PINS| SPICOMMON_BUSFLAG_SCLK|SPICOMMON_BUFLAG_MISO|SPICOMMON_BUSFLAG_MOSI,
};

[Sprite]

What pin are you using for the RMT?

[RafaelGD]

explaining my project more specifically, my device has 3 esp32-pico-v3, they have pin 0 (boot) joined, the main esp puts the other 2 in boot when necessary, I also use pin 0 of the main esp with RMT for debug, in the second esp I have an spi peripheral (cs gpio 32, clk gpio 27, mosi gpio 25, miso gpio 26) and when this peripheral is added to the spi bus it interferes with the rmt pin and the debug stops, this behavior does not occur in esp-idf 5.3.1 but in 5.4 it does.

[Sprite]

That is odd, I see no reason why the code would do that with that config. Does it give the error on the latest esp-idf master as well? If so: Any chance you can post your code, preferably whittled down to the minimum to exhibit the issue?

[RafaelGD]

In esp-idf master (https://github.com/espressif/esp-idf.git, v5.5-dev-2375-g1f46216a72) this error does not occur, can we consider it a bug in esp-idf 5.4?

[Sprite]

Yep, feels like something we caught at some time but haven't ported back to v5.4 (yet). You can either switch to master if you're OK with developing at the bleeding edge, or you can file an issue on Github requesting to port this fix back to v5.4 (if we weren't planning on doing that already).