AnsweredAssumed Answered

Changing uSDHC DLL in read path

Question asked by Jason Read on Aug 2, 2016
Latest reply on Aug 15, 2016 by Yuri Muhin

I would like to manipulate the value of the read path DLL associated with uSDHC3 (eMMC) on an iMX6DL SoC in u-boot. The idea being that I would like to create a simple calibration routine that will vary the read delay to identify a passband of eMMC reads and then select the middle value of delay to use for maximum reliability and PVT immunity across different boards.

I am currently booting using SD card on uSDHC2 and trying to communicate using eMMC on  uSDHC3.


1.     It seems like there are two methods for adjusting the read DLL delay. Either setting DLL_CTRL_ENABLE (bit 0) of uSDHCx_DLL_CTRL and updating CLL_CTRL_SLV_DLY_TARGET0 and CLL_CTRL_SLV_DLY_TARGET1 with the desired delay value between 1/32th period and 4 periods




2.     Set DLL_CTRL_SLV_OVERRIDE (bit 8) of uSDHCx_DLL_CTRL and manually define DLL_CTRL_SLV_OVERRIDE_VAL[6:0] (bits 15-9) of uSDHCx_DLL_CTRL to select one of 128 taps of the DLL.


I have tried both options but am unable set up a situation where an mmc read command over eMMC fails. With such a wide range of delays able to be selected, I would expect that when the clock to data delay is incorrect, the eMMC read should fail.


When I try option 1 above, uSDHCx_DLL_STATUS shows that DLL_STS_SLV_LOCK and DLL_STS_REF_LOCK are both set, DLL_STS_REF_SEL[6:0] is always 0000000 and DLL_STS_SLV_SEL[6:0] updates to reflect the desired target delay set in the CLL_CTRL_SLV_DLY_TARGET0 and CLL_CTRL_SLV_DLY_TARGET1 fields of uSDHCx_DLL_CTRL. But regardless of any values of CLL_CTRL_SLV_DLY_TARGET0  and CLL_CTRL_SLV_DLY_TARGET1 I select, I do not see any mmc read failures.


When I try option 2, I set DLL_CTRL_SLV_OVERRIDE (bit 8) of uSDHCx_DLL_CTRL and manually define DLL_CTRL_SLV_OVERRIDE_VAL[6:0] (bits 15-9) of uSDHCx_DLL_CTRL but I do not see any change at all in uSDHCx_DLL_STATUS regardless of any value that I select. I would expect the DLL_STS_REF_SEL[6:0] field to reflect the currently selected reference tap but again, it is always zero.


My questions are:


1.     Is my understanding of how to manipulate the read DLL register correct?

2.     Is it possible that I am not actually changing the DLL settings like I think I am?

3.     Are there set steps I need to follow to manipulate the read DLL when the eMMC interface is already running?

4.     Why do I not see mmc read failures when I set the delay value to anything within the range of reference taps using either method in u-boot? I expect some values to pass and some to fail.


Any help is very much appreciated.