SD/SDIO tuning registers

[carstenhansen]

We are having some difficulty with SDIO tuning on an iMX7D design, using a third-party WLAN module connected to the uSDHC1 interface, running in SDR104 mode.

The Linux driver implements standard tuning by default, however this has turned out to cause some instability as we observe occasional CRC errors on received data, typically within a few minutes.

Modifying the driver to use manual tuning instead seems to have solved this issue. However, we are struggling to understand the meaning of some bit groups in the uSDHC block.

From the iMX7D Reference Manual, rev 1, Jan 2018:

1. p2892, uSDHCx_CLK_TUNE_CTRL_STATUS, the table refers to CLK_PRE, CLK_OUT and CLK_POST. What exactly are these clocks, where do they come from, and where do they go to? They are obviously important, but we can't find any mention of them anywhere else in the RM
2. p2896, uSDHCx_STROBE_DLL_STATUS, there's mention of a reference delay line as well as a slave delay line. What are those? Figure 10-54 on page 2815 only shows a single delay line
3. p2904, uSDHCx_TUNING_CTRL, what is the significance of the TUNING_WINDOW bit group? The description has "Select data window value for auto tuning" but we're not sure what that means

We've gone through the SD Specifications including the Host Controller spec, but have been unable to find more information. And in any case this seems to be processor specific, so probably wouldn't be documented there.

Any insights much appreciated.

Thanks,
Carsten

[Yuri]

Hello,

  look at my comments below.

1.

  Generally the mentioned CLK_PRE, CLK_POST, CLK_OUT are internal ones.

Customers can use Figure 10-36 (ultra Secure Digital Host Controller Block Diagram)

and Table 10-41 (uSDHC Clocks) of the i.MX7D RM regarding uSDHC clocks.

 usdhc_clk_root is base clock; Table 5-11 (Clock Root Table) shows this clock sources

(CCM_TARGET_ROOT[MUX]). Figure 5-15 (CCM Clock Tree Root Slices) demonstrates

PRE and POST (PODF) dividers.

2.

  On the mentioned Figure 10-54, “reference delay line” means input, reference ipp_card_clk_in,

“slave delay line” means the delay line output ipp_card_clk_in_dll.

3.

  The tuning is described in Appendix D (UHS-I Tuning Procedure) of the SD specs, but is is not

provided in the Simplified Specification.

Have a great day,

Yuri

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

[carstenhansen]

Thanks Yuri,

1. These clocks being internal, does that mean customers should not use the corresponding bitgroups as their function is undocumented?

The manual tuning procedure in the Linux driver does adjust DLY_CELL_SET_PRE (i.e. CLK_PRE), but not CLK_POST and CLK_OUT though.

I had another look at Figure 10-36, but don't see those clocks documented. I suppose CLK(output) might be CLK_OUT, but what about CLK_PRE and CLK_POST then?

You mention the PRE and POST dividers on Figure 5-15. but the bitgroups in uSDHCx_CLK_TUNE_CTRL_STATUS are specifically delay cells, not dividers. Maybe I'm misunderstanding what you're saying.

2. Sorry I'm not sure I follow this. The RM talks about two distinct delay lines (reference and slave), and describes how to configure the delay or number of taps for each one. But Figure 10-54 only shows one delay line. So if the reference delay line signifies an input, and the slave delay line an output, then is it really a single (i.e. one) delay line that can be configured through uSDHCx_STROBE_DLL_STATUS?

It just doesn't make sense to me to refer to an input or an output as a delay line. So if I configure the reference delay line for 10 taps, and the slave delay line for 20, would that introduce a total delay of 30 taps between ipp_card_clk_in and ipp_card_clk_in_dll?

3. We are familiar with the tuning procedure (which is in fact described in the Simplified Host Controller A2 spec, and in greater detail than Appendix D).

What we don't understand is the function of the TUNING_WINDOW bitgroup.

In SD spec parlance, the tuning window is the (measured) timing interval where communications with the card succeed, i.e. it is inherent to the hardware design and not something one might change by writing to a register in the host controller.

[Yuri]

Hello,

1.

   The uSDHCx_CLK_TUNE_CTRL_STATUS is status register - for read.

2.

   Sorry for some inaccuracies in our documentation: it is the single delay line with 

input and output and corresponding events: proper (detected) input and output clocks.

 3.

   Customers can select data window value for auto tuning.

Also use AUTO_TUNE_EN bit in uSDHCx_MIX_CTRL register.

Regards,

Yuri.

[carstenhansen]

Hi Yuri,

1)

Appreciate your feedback, but I believe this is actually incorrect.

uSDHCx_CLK_TUNE_CTRL_STATUS is a combined control and status register, and some bits are indeed writable, specifically DLY_CELL_SET_PRE, DLY_CELL_SET_OUT, and DLY_CELL_SET_POST.

10.3.8.25 in the RM does state that all bits are read-only, however the figure in the same section shows bits 0-14 as writable, the description further down implies the same by saying those bits are used to "set" a number of delay cells.

Also, the memory map in 10.3.8 has the register as R/W, and the TSCD bit in uSDHC_PRE_STATE is used to wait for writes to uSDHCx_CLK_TUNE_CTRL_STATUS to become effective.

And of course, the current Linux driver writes to uSDHC_CLK_TUNE_CTRL_STATUS to implement manual tuning.

2) and 3)

I'm still not sure we understand the function of those registers.