ESP32 Forum

Dear Espressif Support Team,

We are using the ESP32-C6 module on our custom embedded board. The ESP32-C6 is connected to another microcontroller via SPI on the same PCB.

System Configuration:
ESP32-C6 configured as SPI Slave
External MCU configured as SPI Master
Development framework: ESP-IDF
Example used: spi_slave (receiver example) SPI receive function used: spi_slave_transmit(RCV_HOST, &t, portMAX_DELAY)

Current Setup:
SPI clock from master: 50 MHz
Packet size: 1024 bytes
2 ms delay between packets (required for stable communication)

We are able to receive data correctly when a 2 ms delay is inserted between packets on the master side. However, if we remove this delay, packets are lost.

Our final goal is to:
MCU (SPI Master @ 50 MHz) → ESP32-C6 (SPI Slave) → WiFi UDP transmission
Target throughput: 50 Mbps over WiFi.
We would like clarification on the following points:
What is the maximum supported SPI clock frequency for ESP32-C6 when operating in SPI slave mode using spi_slave_transmit()?
Is 50 MHz officially supported in slave mode?
Are there limitations depending on IO MUX versus GPIO matrix routing?
What is the maximum practical SPI throughput achievable in slave mode under continuous transfer conditions?

Is achieving 50 Mbps end-to-end throughput (SPI to WiFi UDP) realistically feasible on ESP32-C6 considering SPI driver overhead, FreeRTOS scheduling, and WiFi stack performance?

We would appreciate your guidance on the maximum supported SPI slave clock, achievable throughput, and the recommended architecture for high-speed SPI-to-WiFi data streaming.

This project is fully completed except for resolving this SPI throughput issue, and it is very urgent for our release timeline. We kindly request your priority support on this matter.

Thank you for your support.

Best regards,
Srikanth
Sr. Embedded Engineer
Sigma Advanced Systems Ltd.

We have reduced the master clock frequency to 32 MHz, then also, we are still observing the same issue as before.

Please let us know the next steps for further debugging or if any additional information is required from our side.

Try spi_slave_queue_trans() to make sure there's at least one transaction 'in flight' at any time.