Hi all- new here.
I'm writing a customized driver for SD/MMC/eMMC using the i.MX53 Sabre as my platform, and have run into a peculiar issue. This is using the Windows Embedded Compact 7.0 BSP, and the driver interfaces with the BSP's ESDHC implementation.
My driver uses open-ended multi-block reads and writes as it's preferred transfer method, and it works fine if the transfer sizes are less than 8 blocks. However, at 8 blocks or higher, it hangs. I find that my driver is waiting on a reponse for a STOP_TRANSMISSION command (CMD12), and the ESDHC thread is stuck in a loop at line 2294 of esdhc.cpp. Here is the code around that line:
2291: // poll on DAT[0] for busy signalling
2292: if (CSP_BITFEXT(&m_pESDHCReg->XFERTYPE), ESDHC_XFERTYPE_RSPTYP) == ESDHC_RSPLEN_48B)
2293: {
2294: while (! (INREG32(&m_pESDHCReg->PRSSTAT) & (CSP_BITFVAL(ESDHC_PRSSTAT_DLSL, 1)));
2295: }
What it is trying to do is look for the DAT[0] line to indicate that the device is no longer busy, in accordance with eMMC specifications for the R1b response type, which CMD12 uses for writes. This signal is never indicating that the device has come out of the BUSY state, and line 2294 essentially becomes an infinite loop. This only happens if the size of the transfer is 8 blocks or more.
In researching the issue, I have noted that there are erratas for the SD/MMC/eMMC host controller for CMD12. However, the code in the BSP seems to have already been adjusted for those. I also tried using the AUTO_ISSUE_CMD12 feature on my open-ended multiblock operations, but it seems like BSPis not set up for that and the device doesn't come out of the DATA state.
Has anyone else seen this? If so, advice would be much appreciated.
