CKE is not asserted after re-initializing DDR controller.

[norihiromichiga]

Hello Freescale team,

Our customer is using Vybrid device and their production has already started. Recently, they found a problem(DDR initialization is not completed) on some of their system at the field.

Now they are investigating why DDR initialization is not completed, but they have not narrowed down the root cause yet.We need your help what portion we should focus on for further investigation.

====================

Problem statement

====================

First, here is problem they faced.

After the system normally started, we put the device into LP stop 3 mode. And when this device is returned from this low-power-mode to normal-operation-mode, DDR initialization was not finished sometimes. (CKE has never been asserted.)  The rate of occurrence of this issue is not 100%. But they can duplicate it around 70% on the specific non-working system.

=====================================

Usage scenario and other observation

=====================================

Question )

Could you advise us the condition when CKE pin is asserted? According to RM, the condition of asserting CKE pin is,

  "Asserted— Activates internal clock signals and device input buffers and output drivers."

How DDR controller recognizes that "internal clock signals and device input buffers and output drivers" are activated?

The status of PLL (locked or not locked) for DDR controller?

IOW, we want to know the possible conditions where CKE pin is never asserted, even though we initialized the register for DDR controller.

Thanks,

Norihiro Michigami
AVNET

[norihiromichiga]

Hello Jiri-san,

Thank you for your reply.

There was typo in Q3 in my previous question. I meant DDRMC_PHY03, not DDRMC_PHY11. Sorry.

So, your information about PHY03/19/35: Master control is fine. Thanks.

You set 0x0001012a into PHY03/19/35, we set 0x00040404 into PHY03/19/35, based on the information in the following link, lpddr2_400mhz_golden.c

Executing from LPDDR2

Our important question is that if we should set 0x0001012a to PHY03/19/35?   (Even 0x00040404 is specified in lpddr2_400mhz_golden.c.)

Please advise us.

And here is answer for you.

> - CA5_CLK_SEL

  PFD4 of PLL1 is selected for CA5 clock.

  We set  0x1E to PFD4.

  We set 480MHz to PLL1.

> - DDRC_CLK_SEL

  PFD2 of PLL2 is selected for DDR clock.

  We set 0x22 to PFD2.

  We set 480MHz to PLL2.

> - if SYS_DIV_OUT_CLK which source or PFD.

    We don't set divider for SYS_DIV_CLK_OUT.

    So, CA5 clock is directly fed from PFD4 of PLL1.

In fact, we already errata, e6235 and we take into account that.

We think we don't hit this errata, but please double check it for us.

Thanks,

Norihiro Michigami

AVNET

[jiri-b36968]

Hello Norihiro-san,

PHY03/19/35:

     0x __0004____ you increased requirements to consider DLL is locked from 1 to 4 per 8 clock. harder to lock. It is not recommended but if it works for you better, then use it.

     0x ______04__ you give more time to DLL lock. It is not recommended but if it works for you better, then use it.

     0x ________04  starting point seems to be too small. Then it takes more time to DLL lock. Please increase it - so it is closer to DLL_LOCK_VALUE (on your system was about 5F).

So your CA5 frequency is 288MHz and DDRC frequency is 254MHz ? There is a note in RM (9.7 Clock configuration) that minimal DDR frequency is 300MHz.

what is state of PLLx lock and PDFx_STABLE bits?

what is setting of PLL? MFI, MFN and MFD?

are in the system any PFD with divider 19 enabled?

/Jiri

[norihiromichiga]

Hello Jiri-san,

Thank you for your update.

Here is answer to your question.

>So your CA5 frequency is 288MHz and DDRC frequency is 254MHz ?

Yes, correct.

>There is a note in RM (9.7 Clock configuration) that minimal DDR frequency is 300MHz.

We know that. But on the other hand, RM also describes a setting for 250MHz.

So, we believe we could configure DDR freq less than 300MHz.

> what is state of PLLx lock and PDFx_STABLE bits?

Yes, once we enabled PLLx, we could see STABLE bit indicated the stable state.

>what is setting of PLL? MFI, MFN and MFD?

MFI            =>  20(decimal). It is corresponding to 480MHz.

MFN/MFD =>  We don't change the default from RESET values.

> are in the system any PFD with divider 19 enabled?

As you can see, we don't use 500MHz of system clock. So we think we don't hit known errata.

But anyway, we didn't set 19 to divider of PFDs.

And here is our new questions.

1) Maser/Slave DLLs.

I know some PHY settings are depending on the type of DDR (DDDR3 or LPDDR2).

But I think DLL is common function for DDR3 and LPDDR2.

IOW, customer is using LPDDR2 with Vybid, but we can use FSL's recommended settings for DLL that are verified by FSL using evaluation board of Vybrid which uses DDR3. Correct?

Please let us know if this understanding is correct.

2) PHY03 settings

When customer set following setting from 0x4 to 0x1 that you recommended, then, the problem was gone.

PHY03/19/35:

0x __0004____ you increased requirements to consider DLL is locked from 1 to 4 per 8 clock.

0x ______04__ you give more time to DLL lock.

So, we believe "golden sample" we received from FSL was wrong  (or not optimum).

We can't find the these bits in RM, so customer couldn't doubt these settings were not correct.

We don't ask FSL to explain reason why FSL recommended 0x4 at that time, but we need a good justification (logical explanation) that allows us to ask our customer to change the these settings. (Because their system is already in production and it is not easy to change these settings now)

Could you advise us the reason why FSL recommends 0x1 to these bit?

Our expected explanation from FSL is like this:

FSL already verified that it is sufficient to indicate that DLL locked to the clock when phase was detected once within 8 cycles for proper DDR3/LPDDR2 operation, provided that the accuracy of clock that customer added was within xxx ppm and power supplies customer uses are stable (+/-5% of nominal voltage).  Based on FSL's validation, FSL set 0x0001012a to PHY3 in FSL's u-boot code. "2a" may be adjusted by customer depending on the DDR clock rate, but 0x000101__ should not be changed.  Freescale will update RM to describe this point in the future release. Etc...

3) "Number of DLL lock indications must received" in PHY03.

I understand the meaning of this bit. If we set 2 or higher to this bit,

it means that DLL must receive consecutive "lock indications" by specified number of times within 8 cycles?

For ex,  if we set 0x4 to this bit, DLL must receive four consecutive lock state(* mark in my diagram) like below?

1         2        3          4        5         6         7        8 cycles

|~~|__|~~|__|~~|__|~~|__|~~|__|~~|__|~~|__|~~|__

           *         *         *          *

           Lock  Lock  Lock   Lock

or Lock bit doesn't need to be in series like below?

(if 4 lock bits are seen within 8 cycles in total, Master DLL can tell salve DLL that master DLL is locked.)

1         2        3          4        5         6         7        8 cycles

|~~|__|~~|__|~~|__|~~|__|~~|__|~~|__|~~|__|~~|__

           *                    *         *                     *

           Lock             Lock  Lock              Lock

Please let us know if which idea is correct.

Thanks,

Norihiro Michgiami

AVNET

[jiri-b36968]

Hello Norihiro-san,

1. yes

2. 0x04 was used during validation. Final recommendation for reference design was 0x01.

3. Good question. Since we recommend to use 0x01 it does not matter. Anyway, asked designers already.

/Jiri

[norihiromichiga]

Hello Jiri-san,

We decided to use '1' for "Number of DLL lock indications must be received" setting.

So you don't need to answer my question #3 in my previous comment,

Instead of that , I have two urgent questions.

1) Side effect from changing "Number of DLL lock indications must received".

We believe that there is no side effect even we change this setting from 4 to 1. Correct?

Because this bit just changes the probability of lock and once the master DLL is locked,

it will not affect any run-time behavior of Vybrid.

2) About DLL_WRITE_INC.

I think Freescale recommends that we set '1' to this bit.

But even we set '4' to this bit, this doesn't affect the probability of lock, correct?

We think this bit controls the number of "delay tap" that DLL increases when DLL searches the phase like below.

|     |     |     |     |     |    DLL_WRITE_INC = 4

| | | | | | | | | | | | | | | |    DLL_WRITE_INC = 1

+-----------+

|               |

|              +-----------+

If we set '4' to "DLL_WRITE_INC", this setting is "coarse" comparing to '1'.

But DLL should be able to lock to the clock eventually. 

If my understanding is wrong, please let me know why Freescale recommends '1' to this bit.

Thanks,

Norihiro Michigami

AVNET

[jiri-b36968]

Hello Norihiro-san,

1. No side effect. When set to 1 than probability that DLL is considered as locked is higher.

2. Yes 1 is smoother. Because on Vybrid use about 60 delay blocks per one clock period (400MHz), it is better to use 1 element step. This affect also time to lock. Lower value makes precise increment when search for lock- reason to set to 1 by Freescale. Original descriptions is "DLL_WRITE_INC: This value is the incremental interval that the PHY will use from the DLL initialization point to search for a lock. "

/Jiri

[norihiromichiga]

Hello Jiri-san,

Thank you for your answer.

As for #2, please let me clarify how this bit affects "precision of delay element" and "time to lock".

I thought "precision of delay element" and "time to lock" was trade-off.

Could you take a look at attached slides?

Pg1 shows the case where DLL_WRITE_INC = 1.  I believe my understanding is correct more or less.

For DLL_WRITE_INC is not 1, I can assume two kind of result.

Pg2 shows the case where DLL_WRITE_INC = 4 and the accuracy is worse than INC=1.

Pg3 shows the case where DLL_WRITE_INC = 4. The measurement accuracy of clock is same as INC=1.

Could you advise us which slide (pg2 or pg3) correctly illustrates the behavior of DLL?

Thanks,

Norihiro Michigami

[karina_valencia]

jiri-b36968​ are you able  to continue with the follow up?

[jiri-b36968]

Hello Norihiro-san,

nice slides. Assumption 1 is correct - reason for recommendation to set it to 1 by Freescale.

/Jiri

[norihiromichiga]

Hello Jiri-san,

Thank you for your comment.  I really appreciate your steady help on this long thread.

Now, I don't have any questions about DDR controller on Vybrid device.

I believe I could solve original issue (CKE is not asserted due to unlocking state of master DLL) by adjusting PHY registers.

Finally, here is request that I asked through local Freescale team.

   DDRMC_PHY03, 19 and 35 in RM for Vybrid should be updated to cover the following points.

   1. Recommended value for DLL_LOCK_NUM should be '1'.

   2. Recommended value for DLL_WRITE_INC should be '1'.

I believe these update can prevent Vybrid users from facing the similar issue to us.

Again, thank you for your help and I closed this ticket.

Norihiro Michigami
AVNET

[jiri-b36968 · Accepted solution]

Hello Norihiro-san,

have some updates:

1. Lock condition for DLL_LOCK_NUM ==4. 

     Considered as not locked: 0b10101010

     Considered as locked: 0b11110000

2. Just small correction of your picture above: There are three masters and three slaves DLL - each pair for one data slice.

3. In PHY03,19,35 is undocumented field bits 22:20 which sets Phase_detect_sel. It is number of delay elements between lock detectors. Default is b000 which is one element. Please increase it from 2 elements 0b001 up to 5 elements 0b100

Other bits sets Master DLL:

     0x __X_____ 22:20 sets number delay elements between lock detectors.

     0x ___X____ 19:16 sets number if LOCK indications to consider as LOCKED.

     0x ____XX__ 15-8 sets time to DLL to lock. It can help to lock - bigger value = more time.

     0x ______XX 7:0 sets DLL starting point.

We set 0x0001012a into PHY03/19/35 where starting point of DLL = 2A, Increment = 1,  number of indications =1, number of delay element = 1 (0b000).

When number of delay element is increased, then number of indication have to be increased.

Please change it up to 0x0042012A

This should help to DLLs lock, stay steady and CKE is asserted.

4. To close this ticket please click on "correct answer" button

/Jiri

[tomokiokuno]

Hi,jiri,

>Please change it up to 0x0042012A

1. Is its setting value effective in all customers boards?
2. Is its setting value final decision?
3. Is this issue a document errata?
4. When is its setting value described on a reference manual?

Regards,
Tomoki

[jiri-b36968]

Hi Tomoki-san,

0x0042012A is valid value. Current default value 0x0001012A is also valid value, but it requires precise design of the board.

Because of it and after whole temperature testing on wide batch of samples we recommend 0x0023012A as the best starting value. (3 delay elements on lock detector, 3 indications to consider as locked, increment 1, 0x2A starting point. If all is OK use this value.

If your board is perfect you can go down to 0x0013012A to get more precise timing - not necessary.

If it still gets unlocked frequently go to 0x0033012A.

You can go up to 0x0053012A - but you need to test it - because it makes too much tolerance on the clock and think about board redesign.

We decide to recommend to use 3 lock indications always to be sure, that it has locked on correct value.

Starting point depends on the frequency of course. We tested on 400MHz - 2a is good value.

RM is updated right now - not sure what is release date.

Linux and MQX will be patched soon.

/Jiri

[jiri-b36968]

Hello Norihiro-san,

additional information regarding your question about power supply:

- Oscillator XOSC uses 1.1V - pin DECAP_V11_LDO_OUT

- PLLs use 1.1V and 2.5V  DECAP_V25_LDO_OUT

- SDRAM controller is using 1.5V and 2.5V (Phy including DLL) and 1.2V logic

/Jiri

[norihiromichiga]

Hello folks,

After that, we found that the problem could happen at the power-up time as well as wake-up time from the sleep mode.

We think that power-up sequence at power up time is less complex comparing to the wake-up time, so first, we think we should focus on the problem at power-up time rather than the problem at the power-up time.

Still we want to confirm the internal logic in DDR controller which controls CKE pin.  (We believe this pin is not controlled by our firmware.)

Thanks,

Norihiro Michigami
AVNET