esp_vfs_fat_sdspi_mount function in the ESP-IDF framework, but it's failing with a CRC error

[samsfisherCsy]

Describe the bug

I'm trying to mount an SD card using the esp_vfs_fat_sdspi_mount function in the ESP-IDF framework, but it's failing with a CRC error. The card has been formatted as FAT32.

Error Log：

[info] rg_storage_init: Looking for SD Card using SDSPI...
E (909) sdmmc_sd: sdmmc_init_spi_crc: sdmmc_send_cmd_crc_on_off returned 0x106
E (909) vfs_fat_sdmmc: sdmmc_card_init failed (0x106).
[error] rg_storage_init: Storage mounting failed! err=0x106

To Reproduce

Steps to reproduce the behavior:

1. use 4G HC / SanDisk or Other 32GB HC / SanDisk 64GB XC TF Card
2. same format to FAT32
3. put same file
4. 4G HC ,See error Log
5. SanDisk 64GB XC fall in error

esp_vfs_fat_mount_config_t mount_config = {
    .format_if_mount_failed = false,
    .max_files = 4,
    .allocation_unit_size = 0,
};

err = esp_vfs_fat_sdspi_mount(RG_STORAGE_ROOT, &host_config, &slot_config, &mount_config, &card_handle);
if (err == ESP_ERR_TIMEOUT || err == ESP_ERR_INVALID_RESPONSE || err == ESP_ERR_INVALID_CRC)
{
    RG_LOGW("SD Card mounting failed (0x%x), retrying at lower speed...\n", err);
    host_config.max_freq_khz = SDMMC_FREQ_PROBING; // Typically 400 kHz
    err = esp_vfs_fat_sdspi_mount(RG_STORAGE_ROOT, &host_config, &slot_config, &mount_config, &card_handle);
}
error_code = (int)err;
disk_mounted = !error_code;

if (disk_mounted)
    RG_LOGI("Storage mounted at %s.", RG_STORAGE_ROOT);
else
    RG_LOGE("Storage mounting failed! err=0x%x", error_code);

[samsfisherCsy]

SanDisk or Other 32GB HC is OK. Code branch is master

[ducalex]

I'm not sure that I can be of much help. Esp-idf is a little bit picky when it comes to SD Cards, there isn't much we can do.

I have this esp-idf patch to increase compatibility a bit but it might not help you: https://github.com/ducalex/retro-go/blob/master/tools/patches/sdcard-fix%20(esp-idf%205).diff

If you find something we can improve on the retro-go side I'm happy to do it!

[samsfisherCsy]

Thank you for sharing your patch and insights. I really appreciate your help. Following our discussion on SD card compatibility, I came across a well-regarded third-party library called SdFat (github.com/greiman/SdFat), which is widely used in the Arduino ecosystem for SD/MMC cards.

I thought it might be worth looking into, as it could offer us some advantages:

exFAT Support & Robustness: It has built-in support for the exFAT file system (which the ESP-IDF's driver doesn't handle natively) and is generally known for having good compatibility with a wider range of cards in SPI mode.

Feature-Rich: It provides a rich set of features beyond basic read/write.

Considerations for Integration within ESP-IDF (like Retro-Go)

Integrating it into a native ESP-IDF project (like ours) isn't straightforward, but it might be an interesting path to explore if we need those specific features. The main points to consider are:

Framework Difference: SdFat is a C++ Arduino-oriented library, while ESP-IDF's SD/MMC driver is in C. They aren't directly compatible.

Integration Approach: To use it, we would likely need to integrate the SdFat source as a custom component into the ESP-IDF build system and adapt it to use the ESP-IDF's SPI low-level functions to avoid driver conflict.

Compilation: This would require ensuring proper C++ compilation flags and potentially some minor adjustments in the SdFat source for the ESP-IDF environment.

Suggested Next Steps

Perhaps before deep diving into integration, a useful first step could be to test if the cards giving us trouble work reliably with a simple SdFat-based Arduino test sketch on an ESP32. This would help isolate whether the compatibility gain is significant for our hardware.

If the results are promising and we identify a clear need for exFAT or the library's robustness, we could then consider a more targeted integration effort, perhaps starting with a minimal proof-of-concept in a branch.

What are your thoughts? Does this sound like a worthwhile direction to investigate for our specific compatibility issues?

Looking forward to your perspective.

ref:
https://github.com/greiman/SdFat
SdFat-ESP32

[mtojek]

I've seen a similar issue, and unfortunately defaults to separate buses (VSPI/HSPI). I know there is a guide on how to deal with SD card modules, but AFAIK the retro-go project is compliant, @ducalex?

[ducalex]

It might be possible to use SdFat in retro-go but it has significant downsides:

• We have to write a VFS driver to plug into esp-idf, to allow fopen/fread/stat/etc work as expected (maybe your linked repo already made one but I haven't seen it)
• With SdFat it will be impossible to share the SPI bus. That would break many targets.
• It's one more thing to maintain and test.

So I am very reluctant to consider it...

If SDSPI really doesn't work you could try SDMMC instead, or use dedicated bus instead of sharing it

I know there is a guide on how to deal with SD card modules, but AFAIK the retro-go project is compliant, @ducalex?

Hum, we do what they say to not do: Rely on pull-ups... I guess we've been lucky so far, so thanks for bringing that up!

I've made a change in an attempt to resolve the potential problem, please let me know if it is good enough: 8565070

[samsfisherCsy]

Thank you for sharing your detailed analysis and the fix in commit 8565070. I tested the change with a 16GB TF card, and it is now working properly. However, the 4GB card still fails to initialize after the update.

I completely agree with your assessment regarding SdFat. The points you raised—especially the need for a custom VFS layer, the inability to share the SPI bus (which would break multiple targets), and the additional maintenance overhead—are very valid and practical concerns. It makes sense to avoid such complexity unless absolutely necessary.

Your suggestion to try SDMMC or a dedicated bus instead of sharing is appreciated and might be a more sustainable path forward. Also, thank you for addressing the pull-up reliance issue; it’s good to proactively improve hardware compatibility.

If you have any further suggestions or thoughts on why the 4GB TF card might still be failing, I’d be happy to test additional changes. Thanks again for your help and thorough explanation.