Add support for ESP32-C5 flashing over SDIO interface (ESF-240)

[dmartauz]

Is your feature request related to a problem?

ESP32-C5 has potential to become preferred WiFi co-processor due to 5GHz band support.

Describe the solution you'd like

Implementation for both 1-bit (preferred) and 4-bit SDIO would be appreciated.
Please clarify recommended SDIO pin and ESP32-C5 strapping pin configuration in the documentation.

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Hi @dmartauz! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Thank you for your interest in ESP32-C5 and your suggestion regarding SDIO flashing support.

SDIO Support on ESP32-C5

The ESP32-C5 features a hardware SDIO Slave controller that is compatible with SDIO Physical Layer Specification V2.00 and supports both 1-bit and 4-bit SDIO transfer modes, as well as SPI mode. The controller supports a clock range of 0–50 MHz, DMA for data transfer, and configurable sample/drive clock edges. This makes the ESP32-C5 suitable for high-speed co-processor applications, including Wi-Fi offloading over SDIO, and is especially attractive due to its dual-band (2.4/5 GHz) Wi-Fi support ESP32-C5 Series Datasheet ESP32-C5 Technical Reference Manual.

SDIO Pin Assignment

For SDIO operation, the ESP32-C5 uses the following fixed GPIOs (multiplexed via IO MUX):

SDIO Signal	ESP32-C5 GPIO
CLK	GPIO9
CMD	GPIO10
DAT0	GPIO8
DAT1	GPIO7
DAT2	GPIO14
DAT3	GPIO13

Note: GPIO13 and GPIO14 are also used by the USB Serial/JTAG controller, so the USB Serial/JTAG controller cannot be used simultaneously with the SDIO Slave controller ESP32-C5 Series Datasheet.

Strapping Pin Configuration for SDIO

The SDIO sampling and driving clock edge are configured using the strapping pins GPIO25 and MTDI. The configuration is as follows:

Edge behavior	GPIO25	MTDI
Falling edge sampling, falling edge out	0	0
Falling edge sampling, rising edge out	0	1
Rising edge sampling, falling edge out	1	0
Rising edge sampling, rising edge out	1	1

Both GPIO25 and MTDI are floating by default. To set a specific configuration, connect external pull-up or pull-down resistors as needed. The strapping pins are latched at reset and can be used as regular IOs after boot ESP32-C5 Series Datasheet.

Pull-up Requirements

External pull-up resistors are mandatory on the SDIO lines (CMD, DAT0–DAT3) for reliable operation. Espressif recommends at least 10kΩ pull-ups, but 51kΩ are used in some reference designs. Ensure all SDIO lines have pull-ups, and keep interconnects as short as possible to avoid signal integrity issues esp-hosted Linux-based host SDIO setup.

SDIO Flashing Support

As of now, the knowledge sources do not mention official support for flashing the ESP32-C5 over the SDIO interface. The SDIO Slave controller is designed for high-speed data transfer and co-processor communication, but not for initial firmware flashing. Standard flashing is typically performed over UART or USB Serial/JTAG (when not using SDIO). If SDIO flashing becomes supported in the future, it will be documented in the official Espressif documentation and release notes.

Summary

• SDIO is supported on ESP32-C5 (1-bit and 4-bit modes).
• Recommended SDIO pins: GPIO7–GPIO10, GPIO13, GPIO14.
• Strapping pins for SDIO clock edge: GPIO25 and MTDI, set via external pull-ups/downs.
• External pull-ups are required on CMD and DAT0–DAT3.
• Flashing over SDIO is not currently documented or supported.

If you need further details or updates on SDIO flashing support, please monitor the official Espressif documentation and release notes ESP-IDF v5.5 Changelog.

---

References integrated above as per Espressif documentation and Github resources.

[Dzarda7]

@dmartauz Thanks, will take a look at it.

[dmartauz]

@Dzarda7 is there any update? Could you please recommend proper SDIO pin and ESP32-C5 strapping pin configuration? We would like to put our board into manufacturing next week.

[Dzarda7]

Hello @dmartauz, sorry, still under investigation.

• ESP32-C5 is not yet supported and cannot really say when it will be, experimenting now with new chip identification method.
• 1-bit SDIO mode works, it is not implemented yet, but either will be simple change or I will tell you how to do it for your project.
• Regarding the edge control, I cannot really say. Take a look into the docs, it is dependent on your PCB layout, on ESP32-P4-Function-EV-Board these are left floating and it works. I would recommend add some pads for pull up/down resistors and test.
• Regarding other boot pins. Seems like GPIO27 and GPIO28 needs to be controlled. But if you want, I can make second pin optional (or not implement it at all) and control GPIO27 and GPIO28 with one pin of ESP32-P4.

[dmartauz]

@Dzarda7 I think it will be best to pull-down both GPIO27 and GPIO28 using single pin of ESP32-P4. The same pin will actually pull-down BOOT pin of the other RCP. It will be ESP32-H2-MINI module, mainly due to PCB footprint size limitation, we could not fit C5-WROOM module.
We will add pull-up/down resistor footprints for edge control (GPIO25 and MTDI),

[Dzarda7]

I think that I will make it optional to use second pin as someone might want to have lets say fixture where he wants to flash using SDIO and then UART (very unlikely, but better be safe than sorry), that will be impossible with one pin connected to GPIO27 and GPIO28.

[dmartauz]

MTMS pin (IO2) must be set properly as well.

[Dzarda7]

I believe this should be handled either on app level or solved by eFuse. This is not something I plan to implement, but thanks for noticing.

[Dzarda7]

BTW I believe at least modules will come with pre-burned XTAL_48M_SEL_MODE as devkits does.

[dmartauz]

We included pull-up/down resistor footprints for MTMS just to be sure.

[Dzarda7]

Hello @dmartauz, sorry for the long delay. ESP32-C5 is still not in mass production and I cannot verify the detection method on chips that we have now. If you will be in a hurry, I can prepare stub for you for ESP32-C5 and prepare modifications for the library in some branch that you can use, I cannot do more now, sorry.

[dmartauz]

@Dzarda7 are you sure regarding C5 production state? We have several samples of C5-WROOM modules and I was thinking those are MP version. We did not assemble any of them on the PCB yet as we focus on the MIPI interface of P4 right now. I would appreciate if the C5 could be supported in a month or two. Is it feasible?