Error with timeouts constants in stm32f7xx_hal_sd.c in SD_SendSDStatus and SD_FindSCR cause indefinite hangs.

[SGars]

Both these functions contain the code:

"if((HAL_GetTick() - tickstart) >= SDMMC_DATATIMEOUT)"

However SDMMC_DATATIMEOUT is defined as 0xFFFFFFFF so the timeout is very long (49 days with a 1ms tick) and therefore never occurs.

That upshot is that if there is ever an error with the Status-send or Find-SCR functions (which can occur occasionally) then the caller is blocked indefinitely and no further comms with the SD card is possible.

Suggest that these instances should use SDMMC_CMDTIMEOUT not SDMMC_DATATIMEOUT because SDMMC_DATATIMEOUT is defined for use with SDCLK ticks not OS/HAL ticks.

[Imen.D]

Hello @SGars​ ,

Your issue is raised internally for further review.

I will keep you informed about the taken actions/explanation if needed.

Thanks for your contribution.

Imen

[Imen.D]

Hi @SGars​ ,

You are right. In some cases, it can takes few days to write a big size file into an SD card with low class and low frequency.

In fact, this timeout parameter is used in the Read/Write data from/to the SD card, and the necessary time of these actions depends on 3 parameters (configurable by the user):

1- the size of the data

2- the clock frequency used in the application

3- the SD card class

I think the DATATIMEOUT must be variable, to allow the user to define his own Timeout value depending on his application settings.

So, I suggest this solution in order to have variable Timeout Value:

ifndef SDMMC_DATATIMEOUT
#define SDMMC_DATATIMEOUT      0xFFFFFFFFU
#endif /* SDMMC_DATATIMEOUT */

Imen

[SGars]

Hi @Imen DAHMEN​ 

Unfortunatley I think you've misunderstood what I was reporting.

This timeout value SDMMC_DATATIMEOUT is intended for use with the SDMMC peripheral register that specifies timeouts in SDMMC clock cycles - see the other uses in this SDMMC files. In this case the clock is typically 24MHz so the timeout value is 3 minutes which whilst a bit long for a single transaction is at least the right order of magnitude.

However the value has also been used for a timeout where it is compared with system ticks (typically 1 millisecond). In this case it is not approprate because this results in a single transaction timeout of 49 days, which is the error I was reporting. If we reduced SDMMC_DATATIMEOUT to a level where it is appropriate for system ticks then the perhiperal will timeout because it will be too short.

Note that this has nothing to do with writing big files, because this is a single status transaction that is being run here, not an entire file.

A constant SDMMC_CMDTIMEOUT exists in the header which is used in other places to time transactions and is clearly designed to be used as a tick timeout so it seems that this is simply a typo in the driver where in these cases the wrong constant has been used.

Regs,

Steve

[Imen.D · Accepted solution]

I find it different that SDMMC_CMDTIMEOUT cannot be used in the data transfer.

However, the timeout value 0xFFFFFFFF might be a real issue in some cases.

To resolve this, the driver needs to be updated in order to allow to the user to define a reduced data transfer timeout in his proper application.

Imen

[SGars]

Ok, yes understood.

Thanks,

Steve