2018-08-09 12:57 PM
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
2019-05-24 12:59 AM
Well, I thought you are- sorry for my mistake 🙂
2019-05-24 01:01 AM
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.
2019-05-24 03:22 AM
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.
2019-05-24 03:53 AM
@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.
2019-05-24 03:56 AM
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
2019-05-24 04:17 AM
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.
2019-05-24 04:42 AM
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;
2019-05-24 04:46 AM
Replied in the wrong spot, see next post.
2019-05-24 04:50 AM
@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. 🙂