MCU: STM32F777
Cube: 4.25.0
FW: v1.11.0
I'm seeing cases where the F7's SDMMC isn't setting any of the required Status Register bits as the result of
an R1 response to a READ_SINGLE_BLOCK command after having previously handled up to tens of thousands of
identical sequences. The SDMMC_GetCmdResp1() function in stm32f7xx_ll_sdmmc.c waits (with a sad excuse for a
timeout loop) for (SDMMC_FLAG_CCRCFAIL | SDMMC_FLAG_CMDREND | SDMMC_FLAG_CTIMEOUT) to appear in SDMMC_STA.
Aside from a belt & suspenders & duct tape & sandwich board problem-detection approach the SDMMC_GetCmdResp1()
timeout loop should never time out given that, at the very least, SDMMC_FLAG_CTIMEOUT must be asserted after 64
MMC clocks (according to RM0410 Section 39.3.1 and 39.8.11 Bit 2 CTIMEOUT description). And yet the sad
timeout loop does indeed pop.
Attached is a screenshot of a logic analyzer trace showing a CMD17/READ_SINGLE_BLOCK command to an eMMC device
along with its R1 response. The logic analyzer's trigger was SDMMC_GetCmdResp1()'s timeout. There's no MMC
command/response traffic between the R1 response and the trigger, so all interaction with the eMMC stopped
because the impossible happened: there's obviously a response from the eMMC but no indication of any sort made
its way to the SDMMC Status Register. If I understand things correctly, one of the three indications in the
SDMMC Status Register (SDMMC_STA) (CCRCFAIL, CTIMEOUT, and CMDREND) *must* be asserted within 65+48 MMC clocks
after the command is sent.
After SDMMC_GetCmdResp1()'s timeout the SDMMC_RESPCMD contains 0x11, indicating that the SDMMC did indeed
receive the response to the CMD17. The SDMMC seems to have just forgotten to set a Status Register bit.
Examined with an oscilloscope, both the eMMC's CMD and CLK signals look good from a signal integrity
standpoint. No power or noise problems have been noted on any boards. Further, this problem has been observed
on multiple boards, with eMMC's from multiple manufacturers, at different MMC clock rates, and at wildly
variable times while the tests are running.
Thanks,
Dave
