iMX6S: uSDHC and missing CC or CTOE status

[ericjulien]

I'm having a problem that occurs only on a number of my custom boards with an iMX6 Solo (MCIMX6S7CVM08AC) with the uSDHC peripheral where it will not issue a CC (command complete) or CTOE (Command timeout error) status in INT_STATUS (all bits enabled in INT_STATUS_EN) and get stuck infinitely with the CIHB (Command Inhibit) bit set in PRES_STATE. I've verified that the Inhibit bits (PRES_STATE) are clear prior to issuing the command through a write to XFR_TYP and that the command if properly outputted and responded to by the card with an oscilloscope.

The MMC_BOOT DISABLE_TIME_OUT bit is cleared. If I issue a command with no response, the CC bit does assert. VEND_SPEC field INT_ST_VAL is 0 after the during the infinite CIHB high period following the command with a response.

Note that the exact code work perfectly on some units (same board revision, same markings on CPU).

Is there anything that could prevent the command path logic to be disabled or lock-up? Maybe it doesn't detect the command end bit?

Thanks!

[ericjulien · Accepted solution]

I figured it out. It was IOMUXC_USDHC4_CARD_CLK_IN_SELECT_INPUT. It looks like there is an input SD card clock, which I guess the peripheral logic relies on. When I tested it with the platform SDK, I had commented the line that set that register in usdhc4_iomux_config.c because there was a compilation error.

The boards that did work had that register already set correctly. Perhaps it's because of different fuse settings and the boot rom or because I inadvertently had an image on some flash that was running some code before my debugger took over.

Thanks!

[igorpadykov]

Hi Eric

had you tried slow down uSDHC operating frequency ?

Best regards

igor

[ericjulien]

Hi Igor,

thanks for your answer.

I'm running the SD clock at 386 kHz (uSDHC4_CLK_ROOT = PLL2-PFD2@392 / 4 = 99 MHz, uSDHC4_SYS_CTRL_SDCLKFS = 0x80 (256 div)). I also did try setting the uSDHC4_CLK_ROOT divider to 8 to further lower the SD clock to ~193kHz and got the same result (no CC or CTOE).

I've attached the values of the uSDHC4 registers, before the write to CMD_XFR_TYP and after. I didn't clear the status bits. Also note that this specific command should not be responded to, since it's a CMD8 sent before the card is addressed and the device on the bus is an eMMC. I would still expect a CTOE status to be asserted. The results are identical when I try with a command that the eMMC actually responds to, no CC or CTOE.

Regards,

Eric

[igorpadykov]

Hi Eric

since this happens only on some boards, could it be

signal integrity issues, fixed changing drive strength or

bad contacts. Could it be tested with SDK  :

i.MX 6Series Platform SDK : Bare-metal SDK   ?

Best regards

igor

[ericjulien]

Hi Igor,

I suppose it's not impossible that it is a signal integrity issue, but if the controller samples its signals internally, I don't see why this would have an impact. It should have counted 64 clk cycles from the command end bit then issued a CTOE, unless it depends on the external signals to detect the command end bit or clock transitions.

Thanks for the suggestion on trying the platform SDK's usdhc driver. I did and it gives me the same result, with CIHB asserted and neither CC or CTOE or another error bit set. That seems to suggest something with the board is wrong, or the processor is damaged, as I suppose the sdk's usdhc driver has been tested and is known to work.

Regards,

Eric