Why matching SD cards behave differently on the STM32H743i-eval board?

[GreenGuy]

STM32H743i-EVAL w/BSP V1.11.0

SD Cards:

16GB SanDisk MicroSDHC I C4 (circle C with number inside)

16GB SanDisk MicroSDHC C2

Both cards are supposed to be V2.0. Both work in all the SD devices (cameras, PC, thumb drive adaptors, USB readers). When used in the eval board one ( I C4) fails and the other passes initialization. The point of failure is found in stm32h7xx_hal_sd.c at line 3155 where an attempt is made to send the CMD8 app command. The errorstate returned is 4. It does not always fail which makes wonder if there is a timing problem, however when it does fail it is always the same card that is the SDHC I C4 which I believe is the faster card.

When the command passes on the failing card the hsd>instance structure looks like this:

When it fails it looks like this:Along the way, while looking for possible timing problems I came across this in stm32h7xx_hal_s at line 519:

HAL_Delay(1U + (74U * 1000U / (sdmmc_clk)));

which happens just before the SD_PowerOn() is called. According to the comments, it is supposed to cause a wait for 74 cycles after the SD init sequence. Question is 74 cycles of what? Since it is a HAL delay call I assume 74 HAL tick cycles. Careful attention to the code will reveal that the equation in the HAL_Delay argument can't possibly come out to 74 because the sdmmc_clk value is calculated with the goal of being 400,000 or thereabouts. That being so, the HAL_Delay will always be 1. The other wrinkle is that I am using ThreadX and the ticks are set to 100Hz Perhaps this is all rather moot if the 74 cycles are with reference to the 400,000 clock currently driving into the SD card. If so, 1 system tick is plenty.

Still this all looks very odd. It may be someone decided it might be possible that the sdmmc_clk might be as low as 1000Hz, in which case this would insure at least 74 scmmc_clk's.

I extended the delay by forcing a longer time to no effect so I am at a loss.

[AScha.3]

first - i use almost only SanDisk sd cards, because (until now) no one of them died. other (cheap, from China) often suddenly dead.

sec.- even from SanDisk ultra , speed class 10 (number in the circle C) , there are cards just getting the minimum "promised" speed, about 12MB/s writing (>10 is class 10)and 13MB read, but one SanDisk ultra (also from China , Aliexpess) makes 30MB write and 90 MB read (!!!). so there is big spread even on "top" products.

and - i looked with DSO on the command and data line from sdcard, on H743 dev-E-board, testing with constant speed reading for play audio , music PCM/WAV files. very interesting, good card (SanDisk ultra 32GB) always response in 0,9..1,2 ms , delay from command to data coming. cheap "Alunx" (from China) 64GB making most time also 1...3ms, but sometimes up to 30ms delay !

but : none of all cards makes "errors" .

and the cycles delay - i suppose its the command clk , 400kHz (for all card defined same, system clk would make not much sense).

my speed setting: 100MHz , clkdiv 1 ; pin speed high , no DMA + pullups on, 4bit mode, hw control flow ena.

so with your cards, do a speed and quality check (on win : H2testw )

to see, wheter they are really the same and working 100% or not.

[GreenGuy]

This is not about data throughput. It is about basic command response when trying to initialize the card. AScha, your SDMMC1,2 clock is fine. Mine is 200MHz. I have also used 50MHz. What matters is the clock divider in the parameters for the SDMMC clock divide factor that results in the final maximum clock driven to the SD card. This will affect the throughput on a burst. However, this is of no consequence because during initialization the SD card clock line is throttled back to 400KHz. I have seen other implementations throttle back to 100KHz.

I am not certain, but I suspect the problem has something to do with a register not being handled correctly either on the driver side or on the card side. I think that because it looks like, from what I provided for the instance structure, that the CMD8 is not responding as the RESPCMD and RESP1 registers are 0 for the card that does not work.

Thanks for the line on H2testw. Keep in mind though, that program does not reveal what is under the hood with respect to low level drivers. It does not bypass them either. It will tell you command response information that comes directly from the card and obviously it will tell you data throughput. But, besides all that, it still depends on the low level driver that is handling initialization, which on a PC may be much more robust and accommodating than the HAL drivers from STM.

[GreenGuy]

Still would like some feedback on the strange HAL delay equation and its relevance as well as what might be learned from the hsd instance data response for the CMD8 command.