Changing uSDHC DLL in read path

jasongarrison — Tue, 02 Aug 2016 08:47:24 GMT

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.

Re: Changing uSDHC DLL in read path

Yuri — Mon, 15 Aug 2016 08:05:32 GMT

Hello,

Please follow approach, described in section 67.5.3.2.4 [DLL (Delay Line) in Read Path]
of the i.MX6 S/ DL RM. Note, "In override mode, there is no need to set the DLL_enable."

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Changing uSDHC DLL in read path

ken_carlson — Wed, 31 Jul 2019 18:04:21 GMT

Hi,

I am seeing the same symptoms that Jason was seeing where in Override mode, the DLL_STATUS clock status bits never assert (REF_LOCK and SLV_LOCK)?

I am following the 7 step procedure documented in 67.5.3.2.4

Any thoughts?

Thanks

Ken Carlson

topic Changing uSDHC DLL in read path in i.MX Processors

Changing uSDHC DLL in read path

Re: Changing uSDHC DLL in read path

Re: Changing uSDHC DLL in read path