Open yizi15 opened 9 months ago
igrr
commented
9 months ago Please try changing this line: https://github.com/espressif/esp-idf/blob/e49823f10c6b6b8dadbad376002ea2bc531b7b0f/components/driver/sdmmc/sdmmc_host.c#L275 to a larger value, e.g. 500 ms.
We've seen some SD cards which are not compliant with the SD Specification, and do not reply to data transfer commands in 100ms. Perhaps that's what is happening in your case.
yizi15
commented
9 months ago Please try changing this line:
to a larger value, e.g. 500 ms. We've seen some SD cards which are not compliant with the SD Specification, and do not reply to data transfer commands in 100ms. Perhaps that's what is happening in your case.
Thanks, modify the timeout to 500 can solve the problem. I will close the issues after more test.
igrr
commented
9 months ago Let's keep this open... Since more people are running into this, I guess it makes sense to increase the timeout in IDF by default, or to make it somehow configurable. The issue will be closed automatically when we merge the fix.
jliu83
commented
8 months ago Hello, we have just tested this.
We have an application where we are heavily dependent on data + logging on the sd card. The device would run fine most of the time, and occasionally we would get a sdmmc_read_sectors_dma: sdmmc_send_cmd returned 0x107. These errors are annoying because the tasks inside the framework would lock up, and there was no way to detect that this error has occurred. We used a watchdog timer to detect and reboot the system. This method sort of works, unless a sector of the files that are read on boot up triggers a timeout error code.
We kept these SD cards since we started seeing the problem, as they allow us to reproduce this error. While we scoured the forums for a solution and tried several of the proposed solutions, nothing worked, until I read this post.
Changing the timeout from 100 to 1000ms allows all of the old cards to boot up with no issue. I an convinced that the default 100ms is on the threshold for a lot of these cards, and the strict time keeping of the host driver is causing a lot of these cards to fail. The problem with the 0x107 error is that is crashes the entire SDMMC driver. It's okay to timeout, but allow the driver to continue functioning, don't just let it crash. This would make for a more robust driver.
I suggest two modifications to the driver. Allow the data command timeout to be set to a user value (something other than the default of 100) on initialization/mount. Also, when the driver encounters a timeout, do not lock up the driver, allow the driver to recover and retry, and continue functioning.
Thank you for the hint to resolving this. This post has given me a lot of relief and saved me a bunch of headaches.
igrr
commented
8 months ago but allow the driver to continue functioning, don't just let it crash.
@jliu83 Could you please describe the behavior you are observing in more detail? It is not expected that the driver should crash after one of the commands has timed out. If you have the details such as: IDF version, log output, panic output including the backtrace, please open a new issue and put the details there. We'll try to fix the issue and make the driver more robust.
jliu83
commented
8 months ago This might be difficult to do, the SD cards that had the issues all work now, and the blocking file that was causing the error has been overwritten once a successful boot has occurred.
What I suspect is happening is the following.
sdmmc_read_sectors_dma() is called by sdmmc_read_sectors() is called by ff_sdmmc_read(). Then error 0x107 (timeout) is returned from sdmmc_read_sectors_dma() it is propagated all the way up to ff_sdmmc_read(). At this point many of the tasks in the system is halted, or are blocked. We didn't investigate too much at the time. Unfortunately I cannot replicate the error anymore and get the backtrace. If we are able to reproduce I will file a bug right away.
Answers checklist.
IDF version.
release/v5.2
Espressif SoC revision.
esp32s3n8
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32-S3-USB-OTG
Power Supply used.
USB
What is the expected behavior?
通过fopen 打开文件，通过fread 读文件可以正常的读到文件的所有内容
What is the actual behavior?
在某些sd card（32g） 中 通过fopen 打开文件，通过fread 读文件经常读失败， 几秒内重新读取也会失败，写文件正常。 在另一种sdcard (16g)可以正常读写
Steps to reproduce.
将一个大于100M 的文件放入rf card，挂载sdmmc后 通过以下代码读文件 `sdmmc_host_t host = SDMMC_HOST_DEFAULT(); host.command_timeout_ms = 3000; // host.max_freq_khz /= 2; // host.flags &= ~SDMMC_HOST_FLAG_DDR; // This initializes the slot without card detect (CD) and write protect (WP) signals. // Modify slot_config.gpio_cd and slot_config.gpio_wp if your board has these signals. sdmmc_slot_config_t slot_config = SDMMC_SLOT_CONFIG_DEFAULT();
uint8_t buf[512]; const char dst_path = "/sdcard/tst.txt"; size_t all_len =0; struct stat statbuf = {}; stat(dst_path, &statbuf); all_len = statbuf.st_size; FILE f = fopen(dst_path, "rb"); if(f == NULL) { ESP_LOGI("", "tst err"); } else { void p = buf;//malloc(5121024); size_t need_len = all_len; while (need_len > 0) { int32_t read_len = 0; for(int i = 0 ; i < 15; i ++) { read_len = fread(p, 1, 512, f); if(read_len > 0) { break; } ESP_LOGI("", "read fail"); sleep_ms(30); } if(read_len <= 0) { break; } need_len -= read_len; } if(need_len != 0) { ESP_LOGE("","all_len != self->file_size %d, %d", all_len, need_len); } else { ESP_LOGI("","read all data %d", all_len); } fclose(f); }`
Debug Logs.
More Information.
sdcard_readerr.zip