According to the application note in SD Card Physical Specification:
> The host shall set ACMD41 timeout more than 1 second to abort repeat
of issuing ACMD41 when the card does not indicate ready. The timeout
count starts from the first ACMD41 which is set voltage window
in the argument.
Previously, the timeout was exactly one second, and this caused
certain larger-capacity cards to "time out", because they couldn't
finish initialization process in time.
ACMD41 argument is different between SD mode and SPI mode.
In SPI mode, the only non-zero bit may be the HCS bit. Unlike the SD
mode, the bits reflecting the host's OCR should be zero.
Previously, we used to set these bits the same way as for the SD mode.
This has caused certain cards to fail initializing, apparently their
controllers have checked the ACMD41 argument more strictly and refused
to finish initialization, resulting in an error such as
sdmmc_common: sdmmc_init_ocr: send_op_cond (1) returned 0x107
(Note that this error may have other causes than the one fixed in
this commit. For example, if the card doesn't have a sufficient and
stable power supply, it may also fail to complete the internal
initialization process, and will never clear the busy flag in R1
response.)
Closes https://github.com/espressif/esp-idf/issues/6686
Closes https://github.com/espressif/esp-idf/issues/10542
sdmmc, sdspi: fixes related to status checks, R1b response support, erase fix for SPI mode, fix for erase timeout calculation
Closes IDF-4728
See merge request espressif/esp-idf!17727
Previous version of the code used a fixed constant (500 ms) for the
erase timeout and added 1 ms for each sector erased.
This commit improves timeouts calculation:
- For SD cards, check if erase timeout information is present in the
SSR register. If yes, use it for erase timeout calculation.
Otherwise assume 250ms per erase block, same as Linux does.
- For eMMC assume 250ms per erase block (but no less than 1 second).
This has to be improved later to use the erase timeout info in the
extended CSD register.
Same as for write operation, some errors are reported only via CMD13.
Without the R1b response support in sdspi driver, this check would
fail. Now that R1b support is implemented, erase command response is
zero (success) on all cards under test.
Also remove the now-unnecessary card reset after erase in the test
case.
During write operation (CMD24 or CMD25), the card can report some of
the errors in the 1-byte response tokens. Other types of errors are
not reported, the host has to get them by issuing CMD13.
This commit adds CMD13 request at the end of write operations and
reports error to the user if the card status isn't zero.
Numerical value of MMC_SEND_STATUS is the same as SD_APP_SD_STATUS,
so there is no functional change. Just making this consistent with the
sdmmc_send_app_cmd call later on.
options.
Erase command (38) for SD cards allows option for erase/dicard/fule
operation at block level and for MMC cards supports option for
discard/trim at block level. When Sanitize is executed only the
portion of data that was unmapped by a Discard command shall be
removed by the Sanitize command.
Unit test cases added to verify ERASE feature in SD/SDSPI mode.
TRIM/DISCARD/SANITIZE tests for eMMC devices.
Closes https://github.com/espressif/esp-idf/pull/7635
Closes https://github.com/espressif/esp-idf/issues/7623
FATFS provides a disk status and disk initialize callback which were not
implemented. Implementation has very low impact on SD/MMC speed and
fixes issues, when trying to open file when SD card was removed from
slot and not deinited.
If disk_status returns STA_NOINIT, it will always continue with
disk_initialize. If that returns 0, it will continue like everything is
working normally. So there has to be the same check as in disk_status.
Return of disk_initialize is always checked like this for STA_NOINIT or
STA_PROTECT so if command fails, we return the STA_NOINIT.
stat = disk_initialize(pdrv);
if (stat & STA_NOINIT) return FR_NOT_READY;
if (stat & STA_PROTECT) return FR_WRITE_PROTECTED;
Closes IDF-4125
* changing dependencies from unity->cmock
* added component.mk and Makefile.projbuild
* ignore test dir in gen_esp_err_to_name.py
* added some brief introduction of CMock in IDF
SD cards don't support CMD7 (select_card) in SPI mode. Highspeed probe
of sdspi will fail in this step and stop working in highspeed mode.
Remove the CMD7 in enable_hs_mode_and_check to fix this issue.
Please note that, on ESP32, you have to use the IOMUX pins to use sdspi
in 40MHz, otherwise the initialization process will report reading issue
and fail.
DISABLED_FOR_TARGETS macros are used
Partly revert "ci: disable unavailable tests for esp32s2beta"
This partly reverts commit 76a3a5fb48.
Partly revert "ci: disable UTs for esp32s2beta without runners"
This partly reverts commit eb158e9a22.
Partly revert "fix unit test and examples for s2beta"
This partly reverts commit 9baa7826be.
Partly revert "efuse: Add support for esp32s2beta"
This partly reverts commit db84ba868c.
esp_common/esp_compiler: renamed esp_macros file to a more specific one
esp_common/esp_compiler: removed CONTAINER_OF macro, it was a duplicate
components/freertos: placed likely macros around port and critical sections
component/freertos: placed likely macros on lists module
components/freertos: placed unlikely macros inside of assertion points, they likely wont fail
components/freertos: added likely macros on queue modules
FreeRTOS queues are one of most hot code path, because to queues itself tend to
be used a lot by the applications, besides that, queues are the basic primitive
to form both mutexes and semaphores, The focus here is to place likely
macros inside lowest level send and receive routines, since they're common
from all kobjects: semaphores, queues, mutexes and FR internals (like timer queue)
components/lwip: placed likely/unlikey on net-interfaces code
components/fatfs: added unlikely macros on disk drivers code
components/spiffs: added unlikely macros on low level fs driver
components/freertos: added likely/unlikely macros on timers and ticker
freertos/event_group: placed likely/unlikely macros on hot event group code paths
components/sdmmc: placed likely / unlikely macros on lower level path of sdmmc
components/bt: placed unlikely macros around bt HCI functions calling
components/lwip: added likely/unlikely macros on OS port code section
components/freertos: fix code style on tick handler
