cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F7 SDMMC ignores eMMC's response to READ_SINGLE_BLOCK

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

18 REPLIES 18

Well, I thought you are- sorry for my mistake :)

Have you chacked it "in field"? I am checking now solution from link Ive provided. It works well so far.

ST should make something with it.

maciek,

It's been running in about 75-100 fielded units since I discovered the problem in Feburary.

They are essentially the same solution. The solution Hockuba.Krzysztof (Community Member) proposes is to not clear all of the SDIO register flags so when the RTOS context returns to SDMMC_GetCmdResp1 so there is still a flag to trigger it to exit the loop. My workaround was to just add a new flag for the exact same purpose. If using the first one, I'd suggest investigating what other impact not clearing the "missing" registers could/will have.

@mrmichaelblack​ 

Thank you for your responses- I appreciate it.

I am trying the workaround provided by @ChrisH​  and I am still getting some errors- I will try now your solution and I will report If I am still facing this problem.

One thing is sure- ST should do something with it.

I'm using driver written only with CMSIS for some time, it's proven to be reliable :D I'll post it on github if I find some time

Well, we have decided to use ST's MCUs because of Cube and HAL. We wanted to focus on application. The less working on such things the better.

@ChrisH​ If you post it on github please share it. It will help alot. Not only me but all the people facing this problem.

@mrmichaelblack​  BTW, where are you clearing the flag? I am trying your solution but it does not work- I can't even mount the volume.

mrmichaelblack
Associate II

Sorry, missed that bit. I'm currently clearing the flag in the SDIO_SendCommand function:

HAL_StatusTypeDef SDIO_SendCommand(SDIO_TypeDef *SDIOx, SDIO_CmdInitTypeDef *Command)

{

 uint32_t tmpreg = 0U;

 cmdRespStatus = 0;

Replied in the wrong spot, see next post.

@mrmichaelblack​ 

Thank you- clearing it in the begining of SDMMC_SendCommand works. Now I'll make it run (playing wav file) and Ill see if it does stuck. So far so good. :)