This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Dear Sitara Team,
our customer sees an issue with the timing of the eMMC connected to the AM5708.
There are negative setup times for the CMD versus CLK and CLK versus DATA. The clock of eMMC is running of 200MHz, HS200 mode.
A few scope pictures are represented below:
During the project the clock frequency is increased from 50MHz to 200MHz. The timing with a clock frequency of 50MHz is OK.
They noticed that the eMMC is never tuned in HS200 mode as described the SPRACA9.
They found the following in the TRM about it:
Questions:
Thanks and best regards
Martin
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
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
Hello Marcus,
We have not received an answer yet, in the meantime we progressed further, so hence my update and new questions below:
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:
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 Paul,
My name is Dick Bloemen and I am a colleague of Patrick Klok. It is unknown for me whether this is the data/clock driven by the host or device.
The scope probes are connected at testpoints. 4G represents the eMMC. The testpoints are located at the right side of the eMMC. Unfortunately not completely at the begin or end of a transmission line.
It is measured quite close to the eMMC.
Please look below.
The probes cannot be directly connected at the eMMC or AM5708. There are no via's or testpoints available where I can measure at these locations.
The probes are de-skewed. I measured with active differential probes (Agilent 1130A). Basically it represents the timing relation clock and data properly to my opinion.
There is also strange behavior during startup and connecting the probes. If I connect a probe only on the clock, the processor with Linux is starting up properly. If I add a probe on the data line, Linux is crashing during startup. The scope pictures are made when first Linux is starting up and hereafter the probe is connected on the data signal.
When a probe is added on a signal, some capacitance is added and introducing some delay. Linux is crashing when a probe is connected to the data signal. It sounds like that there is an issue with the setup time between data and clock. Can this be the problem?
Kind regards,
Dick Bloemen
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
Hello Paul,
Thanks for your feedback regarding the series resistor in the CMD line. I will consider to remove this resistor.
Kind regards,
Dick