sdmmc_write_sectors and sdmmc_read_sectors will cause failure with 0x109 for all successive calls if it was called with n_sectors=0 (IDFGH-9203)

[wuyuanyi135]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.1-dev-2669-gd152d007c6

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-WROOM-1-N16R2

Power Supply used.

USB

What is the expected behavior?

If sdmmc_write_sectors and sdmmc_read_sectors do not support the argument n_sectors=0, it should be asserted or return error instead of making all successive call mysteriously broken.

What is the actual behavior?

When sdmmc_write_sectors and sdmmc_read_sectors are called with n_sectors=0 all successive to these call will result in error 0x109 (CRC error) or 0x107 (Timeout). These are very misleading error and caused very difficult debugging process.

Steps to reproduce.

Write or read SD card with n_sectors=0 when invoking sdmmc_write_sectors or sdmmc_read_sectors

Debug Logs.

No response

More Information.

No response

[chipweinberger]

Can you show some example code of what you have in mind?

IMO usually you want to fail fast or succeed.

[wuyuanyi135]

@chipweinberger Yes, I would expect exception or assertion if n_sector == 0 is not valid, rather than causing a bunch of CRC error thereafter. However, I am not sure if this behavior is due to the SDCard or esp-idf. I just open an issue here for reference if anyone encounters the same problem.

[adokitkat]

Hi! Thanks for the report. We are discussing n_sector == 0 case returning ESP_OK (0) early, as it follows behavior of many of other C stdlib functions when they operate on "nothing". n_sector < 0 shall return ESP_ERR_INVALID_SIZE . What are your thoughts?

[wuyuanyi135]

Hi @adokitkat. Thanks for your response! Actually, the return value when n_sector==0 does not matter that much. The problem was when the n_sector==0, it caused the following calls to the sdmmc operation failed with misleading error codes (CRC error or timeout). I am not sure if this behavior is reproducible for you or it is specific to my hardware setup. If this problem is common, I would suggest either

1. check the parameter n_sector!=0
2. trace the sdmmc driver and locate where n_sector==0 leads to the error.

[adokitkat]

Since the sector_count (block_count) argument is of unsigned type size_t, it shouldn't accept negative numbers at all and error out at compile time, the < 0 case with ESP_ERR_INVALID_SIZE won't be used after all. Also yes, you're right, we need to find the real reason of these errors as well.

Would you be able to post your whole log output and sdkconfig file here please?

Here is a part of code which could be responsible. I suspect a wrong/corrupt SD command is being sent when block_count is 0. Then datalen is also 0 and opcode is set to MMC_READ_BLOCK_MULTIPLE. If SD card gets in a inconsistent state because of this then it could responds in a way you described. This needs further investigation.

    sdmmc_command_t cmd = {
            .flags = SCF_CMD_ADTC | SCF_CMD_READ | SCF_RSP_R1,
            .blklen = block_size,
            .data = (void*) dst,
            .datalen = block_count * block_size
    };
    if (block_count == 1) {
        cmd.opcode = MMC_READ_BLOCK_SINGLE;
    } else {
        cmd.opcode = MMC_READ_BLOCK_MULTIPLE;
    }
    if (card->ocr & SD_OCR_SDHC_CAP) {
        cmd.arg = start_block;
    } else {
        cmd.arg = start_block * block_size;
    }
    esp_err_t err = sdmmc_send_cmd(card, &cmd);

[wuyuanyi135]

@adokitkat It has been a while since I have workarounded this issue. I need some time to reproduce the problematic project. I will provide it these days.

By the way, is the problem reproducible on your test board? I am not quite sure if this problem is common for different SD Cards.