AM5708: Timing eMMC

Please verify your configuration. Note : MMC1 doesn't support H200

&

(1) - Does not have power cycle support. So if a card fails to enumerate in UHS mode, it doesn't fall back to high speed mode.

Important Info: Certain UHS cards doesn't enumerate in UHS cards. Find the list of functional UHS cards here: processors.wiki.ti.com/.../SD_User's_Guide

Known Workaround: For cards which doesn't enumerate in UHS mode, removing the PULLUP resistor in CLK line and changing the GPIO to PULLDOWN increases the frequency in which the card enumerates in UHS modes.

Please refer to the SD Guide for more information

processors.wiki.ti.com/.../SD_User's_Guide

Hello Marcus,

Power Cycle

On the power cycle, from my point of view this appears as a another issue which we need to pursue looking at your remarks.

Some question son this

1. Does this also apply to eMMC devices ?
2. Is there a way to easily to validate what you ask , as we are using U-boot and Linux (TI repo's) to control the eMMC device, should this not already be covered within these (U-boot/Linux) implementations?

On your question what kind of design we are using, we use a custom design, on which MMC2 is controlling an eMMC device.

We are running for almost a year on HS200 (in a development setting on a small amount of boards), without major issues, as we currently are validating our design, we detected the issue of negative setup and hold times, where we are not operating according to spec (see first post), looks like we are lucky to not have experienced major issues until now.

Looking at the measurements (see first post), this will lead to issues in the future .
To mitigate this issue and to be according to Spec we need to control the setup and hold times.
Besides applying the a_Delay and g_delay's to, we ran into SPRACA9, which is describing DLL TUNING.

For this we need to know more in how and where to perform this procedure, I have summarized the current unknowns below

1. Does the procedure needs to be performed every powerup/initialization ?
2. Is there support (already) available in U-boot and or Linux to take accommodate this process ?
3. Do we need to enable this functionality in U-boot and or Linux or is it already performed already automatically ?

Hello Marcus,

We have not received an answer yet, in the meantime we progressed further, so hence my update and new questions below:

1. We have validated the A_Delays and G_Delays, these are according to MMC2_MANUAL3 (HS200)
   
   
2. We can confirm that within the Linux kernel the MMC DLL Tuning is operational

1. Question: As we use the Linux supplied kernel (4.4.41), can we safely assume this is according to SPRACA9
   
   

• Within U-boot (2016.01), MMC DLL tuning is available but not turned on yet 
  1. As we are configuring HS200 from within U-boot, currently we are enabling this support to have MMC DLL tuning operation.
  2. Question: can we safely assume the MMC DLL tuning within the TI u-boot is according to SPRACA9
     
     
• Within the SPRZ450 Processor errata, I found the following "MMC1/2 SDR104/HS200 Mode DLL Delay Value May Result In Unexpected Tuning Pattern Errors"
  Looking at this issue, potentially there might be an issue with the DLL tuning. Currently the MMC DLL tuning algorithm is 0x40 (64 Decimal), this is higher then the given 40.
  1. Question: is 0x40 (64 decimal) a valid value?
  2. Question: are the U-boot and Kernel configurations implemented according to this Errata  and (SPRACA9)
     
     
• When measuring the setup and hold timing (measuring the clock and a data line), we get issues on the MMC bus and are not able to use the MMC bus, not even on a lower speed.
  The current ways of measuring is to apply the probes after booting the system and the bus is configured for HS200.
  1. Question: Is there a way to measure the MMC2 CLK and MMC2 DATX lines without tampering the bus performance.
     
     
• As the DLL tuning is performed within the SoC and the setup and Setup/Hold time are corrected within SoC (see figure below) and presumably also within the eMMC device, Setup/Hold times are corrected within the SoC and eMMC and thereby this seems to be a systematic approach.
  1. Question: could it be that measuring the setup and hold time on MMC_CLK and MMC_DAT in between the SoC and eMMC is not the correct way to determine whether the Setup/Hold time is according to Spec
  2. Question: What is the correct way in how to determine whether the system is according to Spec

Sorry but these questions are beyond my understanding of the MMC interface.  Please allow me to consult with our MMC experts and they will response to your questions.

U-Boot 2016.01 is old U-Boot and does not implement the DLL tuning algorithm recommended by spraca9. You need 2017 or 2018 LTS releases. Patches which implement it (from 2018 LTS):

aee6e6f117dd (Faiz Abbas) 8 months ago  mmc: omap_hsmmc: Workaround errata regarding SDR104/HS200 tuning failures (i929)
fb3e7b13b3ee (Faiz Abbas) 8 months ago  mmc: Kconfig: Select Thermal configs to support i929 tuning workaround
16fa2eb95172 (Faiz Abbas) 11 months ago  ARM: dra7: Kconfig: Add thermal configs for dra7xx and am57xx
12dd1e5c6a8e (Faiz Abbas) 11 months ago  ARM: dts: OMAP5+: Add support for bandgap sensor in SPL
8502f9f6d778 (Faiz Abbas) 11 months ago  thermal: ti-bandgap: Add support for temperature sensor

Were working on providing recommendations for measuring signal in HS200 mode.

Hello Marcus,

MMC DLL tuning 

Thank you for your reply, i am happy to hear an implementation is already available.

We will try backporting this into our U-boot, we will get back on this.

Validating Design

For us the question is how we are able to validate our current design ?

My assumption is that when using the MMC DLL tuning, this should not affect the physical signals between the SoC and eMMC as the tuning is on the inward paths.
Assuming this, measuring the setup/hold time in between the SoC and eMMC should lead to the exact measurements with negative setup/hold times.

In the situation we have a succesfull MMC DLL tuning, the questions are:

• Is measuring the MMC_CLK and MCC_DAT lines in  between the SoC and eMMC device
  • Is a negative setup/hold timing acceptable at this point ?
• How to validate the entire design is appropriate and according to spec.

Hello Marcus,

We did not received an answer yet, can you provide us with an answer on my previous post in how to validate the design?

The timing relationship of signals sourced by the host and received by the device are defined by the eMMC standard. The device doesn’t require tuning because data/cmd outputs from the host are sourced synchronous to the clock with fixed timing. This timing relationship for AM5708 outputs are defined in the data sheet as delays relative to the falling edge of clock. The maximum delay parameter determines the setup time and the minimum delay parameter determines the hold time relative to the rising edge of clock which the device uses to sample data.

Does the signal relationships captured and shown in the first post of this thread represent data/cmd driven by the host or device?

Also where were the scope probes connected on the PCB?

I ask these questions because the measurements are only valid for data/cmd being sourced by the host when probed at the device pins.

It is also important to de-skew the scope probes to remove any delay difference in the probes.

Regards,

Paul

Hello Dick,

Your reply references a picture or graphic which is not included.

Measuring the delay of data signals driven by the device is not meaningful. You may need to setup a complex trigger where your scope only captures waveforms that fall within the expected data valid window expected for data being sourced by the host.

I'm not sure which head you have on the 1130A probe, but if you are using the probe in single-ended mode the input impedance is 25k ohms. This load may be changing the DC level on the signal which may be causing an issue. I saw a similar issue once where a customer forgot to include a pull-up on D0. Are you probing D0 or one of the other data signals? If so, try probing one of the other data signals.

Regards,
Paul

Hello Paul,

Thanks for your reply. Strange that the picture is lost. I try it another time. Please look below.

The eMMC bus is implemented as represented below:

I spoke this morning with Patrick. During the measurements the used testscript is reading data from eMMC to the processor. I used a differential head. One pin is connected to GND, the other one to the clock and data. Data [0..7] is pulled up with 47Kohm and I am measuring on D0.

It seems to be that the probing is critical. I agree a input impedance of 25K from a probe is tricky in this case..... When I measure with the a passive probe I don't have enough bandwidth. This HS200 mode is new for us regarding design verification. Can you recommended how this interface shall normally be verified? What kind of test setup is required?

Kind regards,

Dick

Hello Paul,

The series resistors of 33ohm (R1417) is used for signal integrity to avoid ringing. We are using these series resistors quite often in general. I am doubting if this resistor has really an effect.

I understand that probing with these 25K ohm probes is causing the problem. Yes especially when communicating at 400KHz is done with open-drain signaling....

Thanks for your recommendation regarding a robust functional test over the voltage/temperature range. Writing patterns like 0x00 with 0xFF and 0x55 with 0xAA will probably stress the MMC bus also for ringing and crosstalk. Timing is also included indirectly, when this is verified over voltage/temperature.

Please let me know you recommendation about to series resistor in the CMD line.

Kind regards,

Dick

Any time the clock is configured in loop back mode, as shown in Figure 25-2 of the TRM, you potentially have the problem described below.

Using the CLK terminal as an input and output simultaneously creates a signal integrity issue at the CLK terminal.  The source impedance of the output buffer and transmission line impedance of the circuit board etch creates a voltage divider at the CLK terminal during rising and falling edges of the clock.  The voltage at the CLK terminal will change by [VDD * (ZL/(ZL + RS))] when the output buffer toggles and will remain at that voltage until it propagates to the load and the reflection returns.  During this time the amplitude of the CLK terminal may be close to the switching threshold of the input buffer.  When the signal voltage is near the switching threshold, noise can cause the input buffer to generate glitches or invalid transitions on the looped back clock.  This will cause problems for the MMC host.  The figure below is provided to help visualize the circuit topology that creates a voltage divider and resultant voltage waveform.

This problem can be resolved by placing a series termination resistor between the CLK terminal and the transmission line.  This increases the amplitude of the CLK terminal voltage divider step above the switching threshold so noise will not generate any glitches.  This resistor should always be placed as close as possible to the CLK terminal that is sourcing the clock.  The value recommended for this resistor is between 22 and 50 ohms.  As the resistor value increases the amplitude of the voltage divider step will increase which provides more noise margin.  However, the maximum clock speed will decrease as the resistor value increases.  The actual resistor value may need to be determined after the circuit board is fabricated and function of interface has been evaluated.

Therefore, you always need a series termination resistor on a looped back clock.

CMD is sampled on a clock edge like all of the DAT signals. The CMD and DAT signals can have signal integrity issues as long as they have reached their valid logic level at least the minimum setup time before the respective clock edge.  I’m not aware of any reason CMD should be treated differently than data.

Regards,

Paul