ESP32 Forum

We have been testing the ESP32 a few weeks now and are amazed by this chip. There is one thing though that bothers/hinders us in the current development of the hardware of one of our projects: SD Card support.
To put this first: this is not a high throughput multimedia type of application but rather data logging related. Therefore squeezing out the last bit of performance should not be necessary here.

We have identified three possibilities to implement SD Card support:

1. via the SD/SPI-Interface shared or instead of the "classic" external flash (pins 28-33)
2. via secondary SD-Pins located at HSPI-/JTAG-Pins (pins 17,18,20-22,24)
3. in SPI-Mode via VSPI (pins 34-36, 38)

All of them have different pros and cons which we can not totally oversee yet. Questions that arose are (grouped for the variant):

1. Here I see a bunch of issues:
- Could SD cards be used instead of the flash as a boot device here? Would this work also in FAT32 if yes
- Is there a timeframe for when there will be documentation/idf-support for this port and/or boot mode?
- Will there be an "out of the box solution" to use sd cards parallel to the main flash ic via different CS-pins?
2. Here only two issues bother me:
- What possibilities would be there to have something like an non conflict mode with JTAG (We would love to keep JTAG. Although we do not necessary need to use it in parallel with SD. Especially as SD card access only occurs at longer intervals.)
- Same as for 1. we would need to have some documentation/lib-support (best case also for FAT32) to get started here quickly. Therefor any hint on the roadmap would be helpful.
3. Here the only critical thing I see is speed. There is at least some support via ported Arduino SD-lib. Do you see any other pitfalls here? Is there some official SD support via SPI planned?

So TLDR: We are on the last steps in the dev process on our board and want to know which SD interface to implement. Our current "fallback/safety net" solution would be to implement (3.) it over VSPI.

I know related questions have been asked in different threads but since there was no clarity on these points I wanted to put all my thoughts together here.

Any feedback on this topic would be highly appreciated!

Hi novalight,

Thanks for the kind words!

novalight wrote: 1. Here I see a bunch of issues:
- Could SD cards be used instead of the flash as a boot device here? Would this work also in FAT32 if yes

No, unfortunately the boot ROM and the flash cache mapping (used for running code stored in flash) only support SPI flash. MMC SPI mode is (as far as I know) different enough that there is no way to make the ESP32 run directly from it.

novalight wrote: - Is there a timeframe for when there will be documentation/idf-support for this port and/or boot mode?

Documentation for the MMC controller is being edited now and should be available in the next technical reference release.

I know ESP_Me-no-dev has been working on MMC & FAT support for both Arduino and esp-idf, but I'll have to check on the progress.

novalight wrote: - Will there be an "out of the box solution" to use sd cards parallel to the main flash ic via different CS-pins?

We don't have an example of this kind, but it's a good idea and we should consider making one.

Sharing the SPI flash with other SPI devices is not overly complicated in principle, there's really only one thing to keep in mind: the SPI flash cache needs to be disabled whenever accessing the other SPI device. In practice, of course, things are not always so simple - in particular code needs to be written carefully to make sure the SD access code doesn't rely on anything stored in the flash, and there can be performance implications from frequently enabling/disabling the flash cache.

If you have enough free pins to avoid sharing this SPI bus, I'd recommed not sharing it.

novalight wrote: - What possibilities would be there to have something like an non conflict mode with JTAG (We would love to keep JTAG. Although we do not necessary need to use it in parallel with SD. Especially as SD card access only occurs at longer intervals.)

You can route either the SDMMC or the VSPI peripheral via the GPIO Matrix to use any free GPIO pins. The gives you a few advantages:

• Using VSPI or SDMMC as the interface becomes a software decision rather than a hardware decision.
• No more conflict with the JTAG pins.

EDIT: Turns out SDMMC cannot use the GPIO Matrix, sorry for this mistake. VSPI can use the GPIO Matrix, if you use the SD in SPI mode.

(The limitations when using GPIO Matrix are running pin transitions at max 40MHz, and adding an additional bus cycle of latency on pin operations. Standard MMC tops out at 20MHz so I'm guessing this is an acceptable restriction in this case.)

Thanks for the detailed reply Angus!

From a hardware point of view I'm tempted to do the following: route the "default" VSPI-Pins to the SD Card interface with two additional pins for if I want to route the native MMC interface via GPIO_MUX.

One thing on the side: I'm still not quite sure on the impact of the mux. The transition max of 40 MHz is in terms of physical rising time on the pins? And for the delay: is it some kind of transition delay or how may I understand it? What does that imply on interfaces like SPI which depend on synchronously clocked full-duplex operations. Will the peripheral drivers inside ESP32 handle this just fine? And the only thin noticeable to the user would be that the input registers would fill a little bit more slowly and the "finish bit" would be set a little later?
Because since we are talking about micro to millisecond operations here. Delays in the order of a few couple nanoseconds are not a concern from an application point of view for me. As long as the drivers handle this properly.

novalight wrote:From a hardware point of view I'm tempted to do the following: route the "default" VSPI-Pins to the SD Card interface with two additional pins for if I want to route the native MMC interface via GPIO_MUX.

I found out today that the SDMMC interface is actually unlike most others and cannot be muxed via the GPIO Matrix, it has to be connected to the physical pins marked in the datasheet. Sorry for giving you the wrong information on this.

You can still reroute the VSPI signals around via the GPIO Matrix, including onto SDMMC interface pins.

So if you're relying on the GPIO Matrix then you'll have to drive the SD card in SPI mode only. Sorry again.

novalight wrote:One thing on the side: I'm still not quite sure on the impact of the mux. The transition max of 40 MHz is in terms of physical rising time on the pins? And for the delay: is it some kind of transition delay or how may I understand it? What does that imply on interfaces like SPI which depend on synchronously clocked full-duplex operations. Will the peripheral drivers inside ESP32 handle this just fine? And the only thin noticeable to the user would be that the input registers would fill a little bit more slowly and the "finish bit" would be set a little later?
Because since we are talking about micro to millisecond operations here. Delays in the order of a few couple nanoseconds are not a concern from an application point of view for me. As long as the drivers handle this properly.

It's a propagation delay, signals (in both directions) have to propagate via the GPIO Matrix, which takes an additional peripheral bus clock cycle (80MHz cycle I believe). So any transition will take the additional cycle to propagate from a register write to the pin transition, and same for reading from a pin into a register. For a synchronous clocked protocol like SPI, this isn't a problem unless your SPI clock rate is coming close to the peripheral clock rate.

You can find SD card signals in PIN MUX documentation, they have HS2_ prefix.

HS1_ is another SD/MMC slot, with 8 data lines, but it will not be initially supported in software.

Low speed signals (like card detect) can indeed be routed via gpio matrix.

ESP_Angus wrote:I found out today that the SDMMC interface is actually unlike most others and cannot be muxed via the GPIO Matrix, it has to be connected to the physical pins marked in the datasheet. Sorry for giving you the wrong information on this.

You can still reroute the VSPI signals around via the GPIO Matrix, including onto SDMMC interface pins.

So if you're relying on the GPIO Matrix then you'll have to drive the SD card in SPI mode only. Sorry again.

Thanks for the clarification! So to be on a safe side I could route the SD-Card to the HS_2 pins (which is indeed only available on a single set of pins via IO_MUX). However this rises two concerns: These pins are muxed with JTAG, so if I was to use JTAG for debugging I should expect some problems? On the other hand: These pins include GPIO2 and GPIO12 - both strapping pins with weak pulldows. As most guides for SD-Card-Implementation and most breakout boards implement pullups on all lines this raises some concerns. I would have to do without the two pullups on these pins.

In the end it would be really helpfull to have some kind of reference implementation of the SD-Interface. From a hardware POV: Are there plans to release something like that, e.g. the WROOVER Schematics? From a software POV it would be interesting to know if SPI and MMC are supported on your planned libs and how the roadmap looks like. Maybe Me-No-Dev could share his status on this topic.

I really hope someone can shed some light on the SD-Card-Interface here.

Actually the current design of WROVER board has this very problem with pullup/pulldown resistors you have mentioned. We will be changing design a bit, and yes, once it is complete the schematics will be released.

Pulldown on GPIO2 is only necessary to go into programming mode, so you can have a pullup there and then add a jumper or a transistor in a similar way you can do with GPIO0. Regarding GPIO12, easiest thing is to program the flash voltage selection efuse to match the voltage used in your design — in this case you don't have to care about GPIO12 state at startup anymore.

Initially the driver is going to have only SD support on slot 1 (HS2_* signals). Slot 0 (HS1_*) support will also be added afterwards. MMC can be added in the future, if there is request for that.

Regarding SPI, ESP_Sprite is working on the driver.

I plan on releasing a preliminary SPI master driver somewhere next week.

ESP_Sprite wrote:I plan on releasing a preliminary SPI master driver somewhere next week.

That sounds good. To be exact here: are we talking "only" about the driver for the SPI-Peripheral here or rather a "full-blown" solution for SD-Cards like the Arduino SD-Lib with SPI driver and FAT32 support? It looks like Lady Ada did a rough and ready port already and Me-No-Dev is working on a more "integrated with ESP-IDF" solution. (As seen here: https://github.com/espressif/arduino-esp32/issues/43 )

ESP_igrr wrote:Regarding GPIO12, easiest thing is to program the flash voltage selection efuse to match the voltage used in your design — in this case you don't have to care about GPIO12 state at startup anymore.

Is there yet a documentation for this feature? One concern here: Since the flash (W25Q64FVSSIG e.g.) is most often not 1.8V compatible wouldn't the problem be that we cannot flash anything at all when booting for the first time (in program mode) but have the flash voltage selection at 1.8V? So there surely would have to be some extra measures (external circuitry, jumper e.g.)?

ESP_igrr wrote:Actually the current design of WROVER board has this very problem with pullup/pulldown resistors you have mentioned. We will be changing design a bit, and yes, once it is complete the schematics will be released.

It really would be great to see how could be dealt with the different constraints here. Since we have finished the rest of our board SD is pretty much the last open question for our hardware design and also for the software. Do you have a timeframe for the WROVER-Schematics. Also if there is some kind of SD-Lib or even example planned it would be helpful to also have a rough estimate on this. Because for these things we always have to determine if it's better to start from the very bottom up perspective or just wait a little longer and spare some head scratching for other problems.

But thanks again for the information so far!

novalight wrote: Is there yet a documentation for this feature? One concern here: Since the flash (W25Q64FVSSIG e.g.) is most often not 1.8V compatible wouldn't the problem be that we cannot flash anything at all when booting for the first time (in program mode) but have the flash voltage selection at 1.8V? So there surely would have to be some extra measures (external circuitry, jumper e.g.)?

I think efuse is programmable through iram stub without any involvement of flash so should be ok as long as you can enter UART boot mode. And actually stub should be able to configure flash voltage too so you wouldn't need to reboot after setting efuse. But if you are pre-flashing flash chips then you still have to add this step to do efuse.