About uSDHC clock duty in SDR104 mode of i.MX6DQ.

[keitanagashima]

Dear All,

Hello.

I have a question about oscillation of uSDHC clock in i.MX6DQ.

Please check the attached file and give me your answer.

Best Regards,

Keita

[igorpadykov]

Hi Keita

such behaviour is caused by impedance mismatch

of SD lines, so reflection occurs. Recommended to check

sect.3.5.8 High speed signal routing recommendations,

sect.3.12 Impedance signal recommendations

i.MX6 System Development User’s Guide (rev.1, 6/2013)

http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf

Best regards

igor

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

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

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

[keitanagashima]

Dear Igor,

Hello. Thank you for your reply.

> such behaviour is caused by impedance mismatch of SD lines,

They are managing impedance in single 50 Ω between i.MX6 and SD card with same all signal length.

And they had already referred to the i.MX6 design guide, too.

Refer to attached file "QA2" sheet.

[Q1]

The duty and frequency looks difference between of the beginning oscillation and behind the stability one.

Is this phenomenon the influence of the layout? really?

[Q2]

Clock was seen lost in the early communication stage (i.e. Before beginning to read / write the data to SD) in SDR104 mode.

Is this right operation?

(If it is abnormal operation, please tell me the workaround.)

Best Regards,

Keita

[igorpadykov]

Hi Keita

1. yes this may be caused by impedance mismatch.

With ideally matched impedance transmitter sees load as

resistive, with unmatched - some reactive (capacitive or inductive) part is added.

Also since processor buffer has own impedances, to account them, it is necessary

to perform ibis modlelling.

2. what do you mean by "Clock was seen lost" ? If small amplitude, had you tried

to increase drive strength ?

Best regards

igor

[keitanagashima]

Dear Igor,

I updated about No.2.

> 2. what do you mean by "Clock was seen lost" ?

The phenomenon was seen only below two part.

i. SD outputs data by CMD19.

ii. SD outputs data by CMD17.

Refer to the attached file "SD_Clock_lost_i.MX6DQ.xlsx".

Best Regards,

Keita

[igorpadykov]

Hi Keita

1. could you try to increase drive strength of clock pad to max.

and set field SPEED=11 (max)

Best regards

igor

[keitanagashima]

Hi Igor,

We tried to increase drive strength. But the phenomenon wasn't seen the improvement.

And, we found the below things.

- The phenomenon appeared after the burst read/write, too.

- In write mode, we didn't find in which timing it occurs

- In read mode, the phenomenon was seen at the timing that start bit was detected.

In UHS mode on i.MX6Q SABRE-AI, the phenomenon was seen too.

What factor is this phenomenon caused?

Is this operation right as i.MX6DQ?

Best Regards,

Keita

[igorpadykov]

Hi Keita

I would suggest to consider this issue with local FAE on site and ask

him (if necessary) to elevate it to application team.

Sorry I do not have more ideas for this issue.

Best regards

igor

[karina_valencia]

dgd​ can you help here?

[admin]

Hi David,

Do you have any input for Keita?

Thanks,

Grant

[david_dicarlo]

I've read through the thread but have some questions.

What is the reason for the question? Are the reads and writes being corrupted or is the question just about the waveforms?

Is this at boot time or sometime later?

Does slowing down the clock change anything or help?

[keitanagashima]

Dear David,

Hello. Thank you for your reply.

> What is the reason for the question? Are the reads and writes being corrupted or is the question just about the waveforms?

[Keita] 

No data was corrupted.

Wishing to confirm whether or not this phenomenon is right operation to you.

The phenomenon looks uSDHC stopped the clock.

We worried about the phenomenon caused data error or performance decline.

> Is this at boot time or sometime later?

[Keita]

It is caused at both of u-boot and kernel on custom board.

And, I confirmed it on the i.MX6Q SABRE-AI with android L5.0.x after the kernel boot-up.

> Does slowing down the clock change anything or help?

[Keita]

In binary image of android L5.0.x, kernel was supported UHS-I(SDR104) at 208MHz (1.8V).

But, the u-boot was supported High speed mode at 50MHz (3.3V).

The phenomenon was seen only SDR104 mode.

Best Regards,

Keita

[TheAdmiral]

Hi Keita,

Could you please supply the schematic section that shows the connection between the processor and the SD Card connector? I am most interested to see if there are any pull up resistors externally and if there are any series resistors on the SD traces.

In looking at the pictures in the attached file SD_Clock_lost_i.MX6DQ.xlsx, I have some following questions:

- In the right picture on the top row, it looks like green trace (CLK@SD) is toggling, but the pink trace (clk@i.MX6DQ) is kept high. Is my interpretation of the screen shot correct? Can you please show me on the schematic the sample point for the two traces?

- In the right picture on the third row, it looks like the blue trace (CMD@SD) and the yellow trace (CMD@i.MX6DQ) match until the point of the blue arrow (Labeled: It looks abnormal operation after a while). And then the blue trace and the yellow trace become opposite each other for ~ 17 clock cycles, then blue trace remains high and yellow trace only toggles. Is my interpretation of the screen shot correct? Do the two traces behave differently during other normal operations, or can this mis-match only be seen during abnormal operations? Can you please show me on the schematic the sample pont for these two traces?

- I am guessing that the SD traces have a series resistor on each trace. If this is true, does the same behavior show up with the series resistors removed? (For now, let us ignore a discussion about reflected signals and the need for series resistors. I would just like to know if the behavior is differenent. None of the Freescale boards have the ability to add series resistors).

Thank you,

Cheers,

TheAdmiral​

[keitanagashima]

Hi Mark,

I updated the clock lost phenomenon on SABRE-AI.

Refer to attached file [SD_Clock_lost_i.MX6Q_SABRE-AI.xlsx].

android L5.0.x pre-build image support UHS-I mode in kernel.

(UHS-I was not supported by u-boot).

So, we confirmed the same phenomenon at the auto tuning by CMD19 on SABRE-AI.

[Question]

We haven't seen any problem actually.

But, the we worry about the phenomenon caused data error or performance decline.

- Is this phenomenon right operation?

- Does this phenomenon cause some problem?

Best Regards,

Keita

[TheAdmiral · Accepted solution]

Hi Keita,

I am sorry this took so long. I had to talk directly to the R&D IP owner to get the exact answer. There is no documentation on it.

Background:

During normal data transfer operations, it is possible for the AHB bus to be heavily used and unable to keep up with the SDR104 transfer rate of the uSDHC module. (During times of heavy usage). If the AHB bus is slowed, it might be possible for the READ FIFO to become so full that the uSDHC module overwrites data that has not be transferred onto the AHB bus. Or it might be possible for the uSDHC module to try to transfer write data to the SD Card before the AHB bus has had a chance to fill the WRITE FIFO with new data.

To prevent data transfer errors, the uSDHC module slows/pauses the transfer of data to/from the SD Card by simply gating the SD_CLK signal for one or more clock cycles. So, if you see the SD_CLK skip a period during normal operations, this is okay behavior.

CMD19 SD_CLK behavior:

The CMD19 command is the "Tuning" command. For SDR104 operations, it is necessary to align the SD_CLK strobe to the center of the valid data window. It is easy for the uSDHC controller to align the clock strobe for Write data, but for Read data, the SD_CLK strobe is routed to the READ FIFO directly from the pads of the processor: In most situations, the strobe would arrive at the FIFO before the SD CARD has even "clocked" the READ data back to the processor. For this reason, it is neccessary to add a "Tuned" delay to the returned SD_CLK to align the clock into the center of the returned data. Figure 67-17 DLL(Delay Line) in Read Path shows an excellent picture of this clock signal.

When the uSDHC module in the CMD19 Tuning period, Freescale has programmed into the Tuning period that every fourth clock pulse is gated. The purpose for this is to ensure that the Delay Line value can properly account for any time during normal data transfer when the uSDHC controller may gate the SD_CLK signal to slow data transfer.

That is why a gated clock signal is so noticable during the CMD19 Tuning period.

But it also may occur during normal data transfer times as well. It is not necessary to be concerned if you see an occassionaly missing clock pulse randomly during normal operations. If you begin to see large numbers of clock pauses during normal data operations, it is because there is a bottleneck of data transfer on the AHB bus. No data corruption is occuring at any time. But if you want to speed up SD Card data transfer in this case, you should consider moving non-essential or back ground data trasfers off the AHB bus or at least delay their transfers to periods when less traffic is happenning.

Please let me know if you have any additional questions.

Cheers,

Mark

[keitanagashima]

Hi Mark,

Thank you for your great information.

OK. I understand that the 1 clock pause is no problem.

If my customer begins to see large numbers of clock pauses during normal data operations, I will explain your 3 advices

Best Regards,

Keita

[karina_valencia]

TheAdmiral​  please continue with the follow up.

[keitanagashima]

Hi Mark,

Thank you for your reply.

I update the below information.

> Could you please supply the schematic section that shows the connection between the processor and the SD Card connector?

[Keita]

I got the connection of SD I/F on custom board.

Please check the attached file [SD_connection_mx6.xlsx].

> - In the right picture on the top row, it looks like green trace (CLK@SD) is toggling, but the pink trace...

> - In the right picture on the third row, it looks like the blue trace (CMD@SD) and the yellow trace...

[Keita]

I'm very sorry... It was my mistakes.

I updated the attached file [SD_Clock_lost_i.MX6DQ_Rev.2.xlsx].

> - I am guessing that the SD traces have a series resistor on each trace.

> If this is true, does the same behavior show up with the series resistors removed?

[Keita]

I ordered my customer it to measure the waveform with the  series resistors removed.

Please wait for a little while longer.

[Keita]

My customer confirmed this phenomenon (lost or stop the SD clock) on SABRE-AI, too.

Could you check it on your environment?

Best Regards,

Keita

[keitanagashima]

Dear Igor,

Hello.

> 1. yes this may be caused by impedance mismatch.

OK. I'll talk to my customer.

> 2. what do you mean by "Clock was seen lost" ?

> If small amplitude, had you tried to increase drive strength ?

Clock was seen lost in the early communication stage only (i.e. Before beginning to read / write the data to SD) in SDR104 mode.

Clock wasn't seen lost after the beginning to read / write the data to SD.

Best Regards,

Keita