Vybrid ProcessorsのトピックRe: CKE is not asserted after re-initializing DDR controller.

CKE is not asserted after re-initializing DDR controller.

Norihiro — Mon, 20 Apr 2015 05:10:57 GMT

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

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Tue, 21 Apr 2015 01:49:54 GMT

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

Re: CKE is not asserted after re-initializing DDR controller.

VilemZ — Tue, 21 Apr 2015 08:21:22 GMT

jiri-b36968 could you take this, please?

Vilem

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Tue, 21 Apr 2015 09:57:41 GMT

Hello Norihiro-san,

CKE signal is asserted during SDRAM controller initiation. Please check DDR_CR80[INT_STAT] and CCM_CCSR[DDRC_CLK_SEL] prior to access SDRAM.

DLL lock is possible to read in DDRMC_PHY11/12, DDRMC_PHY27/28 and DDRMC_PHY43/44

you should see this:

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Tue, 21 Apr 2015 11:01:14 GMT

Hello Jiri-san,

Thank you for your answer.

Customer is polling DDR_CR80 after power-up time, but when the problem happens, the completion bit doesn't indicate the completion of initialization.

As a result, CKE seems to not be asserted for ever. Do you have any idea about the case where doesn't show the completion of initialization?

Enabling DDR_CLK_SEL should be done after CKE is asserted, correct? (IOW, after SDRAM controller init is completed)

And DLL here means that DLL in the PHY on this device? If DLL can't be locked, CKE will not be asserted?

Thanks,

Norihiro Michigami
AVNET

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Tue, 21 Apr 2015 17:12:43 GMT

Hello Norihiro-san,

CKE is controlled from SDRAM controller based on controller mode.

Clock to the controller have to be selected and UN-gated prior to setting any register ( CCM_CCSR[DDRC_CLK_SEL], CCM_CCGR6[CG110] )

Once the controller is set up (CR and PHY registers) then you can start the controller in DDR_CR000[START]. Phy is initiated. Memory is reset. Master DLL have to lock. Then clock to the memory is enabled using CKE. Memory is initiated.

Once all is initiated INT_STAT = 1 ( DDRMC_CR80 bit [8] )

So init sequence is waiting for master DLL to lock.

You can check each slice DLL status in DDRMC_PHY11/12, DDRMC_PHY27/28 and DDRMC_PHY43/44.

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Wed, 22 Apr 2015 01:55:13 GMT

Hello Jiri-san,

Thank you for your detailed explanation.

I missed important information about our case. Our customer is using LPDDR2.

Some features or registers in Vybrid are not applied to LPDDR2 case, but I think past your comment can be applied to LPDDR2 also.

We are going to work with our customer to narrow down the root cause why CKE is not asserted sometimes.

This is my personal question.

I think that DLL in PHY can introduce a small delay so that READ/WRITE operation is done at best point of data eye.

According to your answer, DLL should be locked before DDR clock is enabled by CKE. Is this correct understanding?

I thought that lock of DLL requires the valid DDR clock first, because I thought that phase-detector of DLL requires a valid DDR clock to find the phase.

I'm asking this, because want to check that the internal state of DDRC and PHY are changed correctly step by step.

We think there are some difference in the internal state of DDRC and PHY between working case and non-working case.

Thanks,

Norihiro Michigami
AVNET

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Wed, 22 Apr 2015 08:35:42 GMT

Hello Norihiro-san,

clock is available in SDRAM controller (source and gate) then master dll has to lock and then clock is enabled for SDRAM memory (CKE signal).

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Wed, 22 Apr 2015 13:14:03 GMT

Hello Jiri-san,

Customer still wants to know possible reason why CKE can't be asserted on non-working system.

Sorry to update this comment frequently. I'm adding the register information that were captured from "known good" inventory.

When I compare PHY11 register between known good system and non-working system,

DLL seems to be always locked on know good system. But on non-working system, DLL seems to be unlocked sometimes.

Our customer has two systems that shows the problem (DDR init is not completed) occasionally.

And here is register dumps they provided that may be related to the problem. They dumped registers several times.

Could you take a look at these dumps to see if there are any clue or debug hint for the problem?

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

In case DDR init is ok (working case):

DDRMC_PHY11 0x5E645F00

DDRMC_PHY12 0x001C0017

DDRMC_PHY27 0x5F085F00

DDRMC_PHY28 0x001C0017

DDRMC_PHY43 0x59045800

DDRMC_PHY44 0x001A0004

In case DDR init is ok (working case):

DDRMC_PHY11 0x5E645F00

DDRMC_PHY11 0x5D085F00

DDRMC_PHY12 0x001C0017

DDRMC_PHY27 0x5D005E00

DDRMC_PHY28 0x001C0017

DDRMC_PHY43 0x58085A00

DDRMC_PHY44 0x001B0004

In case DDR init is not completed (non working case):

DDRMC_PHY11 0x5E645F00

DDRMC_PHY11 0x5D646000

DDRMC_PHY12 0x001C0017

DDRMC_PHY27 0x5EA15F00

DDRMC_PHY28 0x001C0017

DDRMC_PHY43 0x58405800

DDRMC_PHY44 0x001A0004

In case DDR init is not completed (non working case):

DDRMC_PHY11 0x5E645F00

DDRMC_PHY11 0x5E905D00

DDRMC_PHY12 0x001C0017

DDRMC_PHY27 0x5E205F00

DDRMC_PHY28 0x001C0017

DDRMC_PHY43 0x58505900

DDRMC_PHY44 0x001A0004

In case DDR init is ok (working case):

DDRMC_PHY11 0x60206200

DDRMC_PHY12 0x001D0018

DDRMC_PHY27 0x60A86300

DDRMC_PHY28 0x001D0018

DDRMC_PHY43 0x5D005D00

DDRMC_PHY44 0x001B0004

In case DDR init is ok (working case):

DDRMC_PHY11 0x61486300

DDRMC_PHY12 0x001D0018

DDRMC_PHY27 0x60806000

DDRMC_PHY28 0x001C0017

DDRMC_PHY43 0x5F005D00

DDRMC_PHY44 0x001B0004

In case DDR init is not completed (non working case):

DDRMC_PHY11 0x61026300

DDRMC_PHY12 0x001D0017

DDRMC_PHY27 0x60126000

DDRMC_PHY28 0x001C0017

DDRMC_PHY43 0x5D005D00

DDRMC_PHY44 0x001B0004

In case DDR init is not completed (non working case):

DDRMC_PHY11 0x60606100

DDRMC_PHY12 0x001D0018

DDRMC_PHY27 0x61046300

DDRMC_PHY28 0x001D0017

DDRMC_PHY43 0x5C005D00

DDRMC_PHY44 0x001B0004

*Note, customer dumped these reigsters after INT_STAT=1.

And here is register info from know good systems. CKE is always asserted as we expected on these known good systems.

1st dump:

DDRMC_PHY11 0x00000D00

DDRMC_PHY12 0x000B0009

DDRMC_PHY27 0x00004300

DDRMC_PHY28 0x001D0018

DDRMC_PHY43 0x5DCF5F01

DDRMC_PHY44 0x001C0004

2nd dump:

DDRMC_PHY11 0x00000E00

DDRMC_PHY12 0x000C000A

DDRMC_PHY27 0x00004300

DDRMC_PHY28 0x001D0018

DDRMC_PHY43 0x5EEB5E01

DDRMC_PHY44 0x001C0004

1st dump:

DDRMC_PHY11 0x00000E00

DDRMC_PHY12 0x000B0009

DDRMC_PHY27 0x00004300

DDRMC_PHY28 0x001D0018

DDRMC_PHY43 0x5F785F01

DDRMC_PHY44 0x001C0004

2nd demp:

DDRMC_PHY11 0x00000E00

DDRMC_PHY12 0x000C000A

DDRMC_PHY27 0x00004200

DDRMC_PHY28 0x001D0017

DDRMC_PHY43 0x5D9B5E01

DDRMC_PHY44 0x001B0004

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

And here is snippet of their code to dump reigsters.

They exectued the code from "ddr_self_1" to "ddr_self_2" repeatedly until CR80::bit 8 showed "1".

ldr r4, =0x0501

str r4, [r3, #0x00] ;DDRMC_CR00

ddr_self_1:

ldr r4, [r3, #0x140] ;DDRMC_CR80

ubfx r4, r4, #0x8, #0x01

cmp r4, #0x01 ;CAL_finish

beq ddr_self_2

ldr r4, [r3, #0x42C] ;DDRMC_PHY11

str r4, [r6, #0x40]

ldr r4, [r3, #0x430] ;DDRMC_PHY12

str r4, [r6, #0x44]

ldr r4, [r3, #0x46C] ;DDRMC_PHY27

str r4, [r6, #0x48]

ldr r4, [r3, #0x470] ;DDRMC_PHY28

str r4, [r6, #0x4C]

ldr r4, [r3, #0x4AC] ;DDRMC_PHY43

str r4, [r6, #0x50]

ldr r4, [r3, #0x4B0] ;DDRMC_PHY44

str r4, [r6, #0x54]

add r5, r5, #1

cmp r5, #0xC00

blt ddr_self_1

ldr r4, =0x0500

str r4, [r3, #0x00] ;DDRMC_CR00

mov r5, #0

ddr_wait_1:

add r5, r5, #1

cmp r5, #0x100

blt ddr_wait_1

ldr r4, =0x0501

str r4, [r3, #0x00] ;DDRMC_CR00

mov r5, #0

b ddr_self_1

ddr_self_2:

On my side, I quickly review above registers.

DDRMC_PHY11::Bit 0 was zero when they read out it, but according to bit 23-16, Lock Indicator shows that DLL was locked in the past.

So, even if we see PHY11::Bit 0 had zero, I think it doesn't prevent the CKE from asserting. (Please correct me, if it is wrong understanding)

In fact I couldn't find critical difference between the working case and the non-working case on their hardware in PHY register values.

So, we may need to check other registers to understand why CKE is not asserted sometimes.

Here is my questions about DLL and lock bit.

1) We believe DLL_LOCK bits are very important for proper operation of DDR PHY.

When you look at our DDRMC_PHY11/12, DDRMC_PHY27/28 and DDRMC_PHY43/44 in attached xls,

do you think that the status of these registers from non-working system is normal and it doesn't affect the asserting of CKE signal?

Or "DLL_UNLOCK_VALUE" should be zero or be small number, if their hardware/PCB is correctly designed?

2) "DLL_LOCK" range can be adjusted by the customer? If so, please let us know the actual register we can change?

The point of this request is that we want to _relax_ the DLL lock range, so that DLL can lock to "bad" signal.

It allows us to see if CKE is asserted on non-working system.

3) DRMC_PHY11/12, DDRMC_PHY27/28 and DDRMC_PHY43/44 are implemented for DQ(15:8), DQ(7:0) and Address lines respectively?

For ex, if Lock bit in PHY11/12 gets set, it means that DLL for DQ(15:8) is locked.

4) There are two DLL_LOCK bit for PHY register pair.

What's difference between PHY11 and PHY12 in the lock bit?

PHY11::bit 0 is lock indicator for Read operation and PHY12::bit 0 is indicator for Write operation?

5) You told me, "So init sequence is waiting for master DLL to lock.".

How can we know the master DLL is locked?

PHY11::Bit 0 and PHY12::bit 0 mean the status of master DLL for the data slice 0?

6) I think CKE is asserted once master DLL is locked.

If my understanding in 3) is correct,

DDR controller waits for "DLL_LOCK" bit in DRMC_PHY11/12, DDRMC_PHY27/28 and DDRMC_PHY43/44 being set at the same time?

If DDR controller can't see these bit are set at the same time, CKE will be not asserted?

I summarized our current observation in attached XLS. We want to make our questions about DLL clear, so please answer my questions above.

Thanks,

Norihiro Michigami
AVNET

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Fri, 24 Apr 2015 15:21:02 GMT

Hello Norihiro-san,

no problem, we will try to locate the issue.

Based on internal description of the controller: SDRAM controller waits for master DLL to lock to enable CKE. There are slave DDLs for each data slice. Lock information can be red in each data slice PHY11,27,43. Unlock generally happen due to clock jitter and/or disturbances on the power.

Please read DLL_LOCK in PHY11,27,43. If all is correct, DLL_LOCK should be always 1. If unlock did not occurred then DLL_UNLOCK_VALUE remains 0.

Unlock event can trigger interrupt (CR80 bit24 is set).

Unfortunately Vybrid reference design is using DDR3. Please send me complete list of the controller setting (registers) and if possible schematic and layout to process further.

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Sat, 25 Apr 2015 02:51:45 GMT

Hello Jiri-san,

Thank you for your answer. We still have some questions.

1) Here is register example we could read from known good system.

DDRMC_PHY11 0x00000D00

DDRMC_PHY27 0x00004300

DDRMC_PHY43 0x5DCF5F01

As you can see, PHY11 shows 0x0000_0D00. It means "DLL_LOCK" is not locked and "DLL_UNLOCK_VALUE" is zero.

Could you advise us how should we translate this state? Based on your answer, ideally, it should be 0x0000_0D01.

(PHY27 also shows inconsistent status. "DLL_LOCK" is not locked and "DLL_UNLOCK_VALUE" is zero. )

2) CR80 register is so-called sticky bit type of register?

IOW, once one of bit in this register is set, it is kept to set until we intentionally clear it by writing CR81?

3) If CR80::BIT 24 is set, it means that salve DLL is unlocked, after DLL is locked?

According to our result, CR80::BIT 24 has not been set on any of their system.

I think it should have '1' on the case where "DLL_UNLOCK_VALUE" is not zero because they don't clear CR80 by writing it though CR81,

4) Master & slave DLL

Based on your answer, I think there is one master DLL & 3 salve DLLs like below.

Only Master DLL affects the assertion of CKE?

I'm still not sure how the lock state of Master DLL and the lock state of Slave DLL affect assertion of CKE.

DDR clock --> | Master DLL |

+------ |Slave DLL for slice 0 |

+------ |Slave DLL for slice 1 |

+------ |Slave DLL for slice 2 |

Thanks,

Norihiro Michigami

AVNET

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Mon, 27 Apr 2015 12:06:07 GMT

Hello Norihiro-san,

1. No explanation for DDRMC_PHY11 = 0x00000D00. The value is strange. Usually it is about 0x40 on our system.

Same for DDRMC_PHY27 = 0x00004300. Lock value is 0x43. Not locked, but no unlock information. Do not understand. Please read the register immediately after.

Meaning of PHY 11/27/43:

From you previous data for example DDRMC_PHY11 = 0x5E645F00

ulocked on: 0x5E

locked on 0x5F

lock history is 110 0100 - unlocking frequently.

2. Yes. Once set in CR80, can be cleared only by write 1 into appropriate bit in CR81. Interrupt is generated only when not masked in CR82 appropriate bit nor mask all bit [28]

3. Bit will be set when initiation is completed CR80[8] and then dfi_init_comlete is changed (DLL unlock). Means - was OK, but it is not OK now.

4. Well it is not 100% clear from the controller documentation. It says clearly that master DLL has to lock. But we presume, that all DLLs has to be locked.

Received documentation via email. Going through.

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Mon, 27 Apr 2015 18:24:04 GMT

Hello Norihiro-san,

an update. There is missing information in current RM in field PHY 02,18, (34). Bits [18:16]. It is number of element for DLL lock.

Please modify your setting to at least 0b001.

we use 0x00210000 for them.

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Tue, 28 Apr 2015 00:51:11 GMT

Hello Jiri-san,

Thank you for your answer.

>1. No explanation for DDRMC_PHY11 = 0x00000D00.

>The value is strange. Usually it is about 0x40 on our system.

For me, 0x40 is also strange. Do you mean you usually see this number for PHY11?

PHY11::bit7-1 are reserved and bit0 is the lock bit. What does 0x40 here mean?

> Please read the register immediately after.

What does "immediately after" mean here? Please advise us more specific timing when we should read this register.

>Here is missing information in current RM in field PHY 02,18, (34). Bits [18:16]. It is number of element for DLL lock.

Thank you for your update. Currently, they are setting '0' for bit18:16: It means one delay tap is inserted between flip-flops.

We will ask them to set '1' to see if what happens on DDL lock status. If problem is not improved, we will ask them to increase it according to your information in previous comment.

This bit controls the delay element for Master DLL? If we can set this number to optimum value, DLL lock state in PHY11 will be set, do you think?

BTW, we send our customer's schematics, layout and PHY/CR register settings through Freescale Japan team.

Did you receive that? If yes, please comment on their schematic if you find any wrong design, wiring etc.... (Please don't attach their schematic to this ticket because it is NDA info)

And you also can find register settings in xls. Recommended register settings we received from FSL last year are included in xls, but we hide it. Please find column B~F in xls to see your recommended setting. I'm not sure if you were involved in generating these recommended values for 200MHz and 400MHz operation at that time, but these numbers are still your recommended setting for this device? If FSL updated this info after that, please let me know.

And in fact, we noticed that our customer was switching two different clock speed (396MHz and 247MHz) for DDR, depending on their usage.

Do you think they should adjust PHY/RC register settings for each DDR clock speed? Currently, they are using the same register settings for 396MHz and 247MHz. Your recommended settings I described above seems to expect two different settings for 200MHz and 400MHz respectively.

Thanks,

Norihiro Michigami

AVNET

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Tue, 28 Apr 2015 07:57:08 GMT

Hello Norihiro,

Yes, I have received it -review it and because of incorrect setting of bits [18:16] in Phy 02 (0x0038005A) I wrote previous comment :smileyhappy:. Without it, DLL will not working correctly. Yes customer can increase it for save lock.

Now I understand 0x5D in locked value - it is because of 247MHz. For 396MHz usually there is 0x40. Yes setting should be for each frequency.

What is reason for two different frequencies?

Customer is using LP-DDR2. Attaching used setting on our reference board TWR-VF65 rev.H (DDR3 setting 9c). Some setting can be useful also for you.

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Tue, 28 Apr 2015 08:20:27 GMT

Hello Jini-san,

Thank you for your reply. We are asking them to run their test with all possible values for bits [18:16] in PHY02 to see if DLL can be locked.

I will update this page once I get their test result. Did you find any other wrong or unexpected settings other than PHY02?

And did you find something in their schematic?

>What is reason for two different frequencies?

Their application is mobile phone, so if their handset doesn't need CPU power, they set lower clock rate to DDR.

When handset requires more CPU power, they set higher clock rate for DDR.

Note, even they use higher freq for DDR only, they still see the same issue.

We will review vybrid.c also.

Thanks,

Norihiro Michigami

AVNET

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Tue, 28 Apr 2015 09:28:13 GMT

Hello Norihiro-san

nothing in the schematic - it is limited only for DDR - so not too much to check. Just one small think - DDR_RESET is output - no reason for pull-up.

Hope that the design includes bulk capacitors 10uF or similar. Self refresh is better way to save power.

Nothing in the setting so far.

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Thu, 30 Apr 2015 10:41:01 GMT

Hello Jiri-san,

Thank you for your answer. I understand that there are no specific suggestion other than DDR_RESET and bulk caps for now.

And sorry, our past information about PHY11/27/43 seems to be not correct.

This time, we believe we could capture the correct number from known bad product.

Please see below.

Note1: No.28 and No.45 means the serial number of products. There are result of OK case and NG case on these two products.

Note2: We captured the register value changing bit 18:16 of PHY2/18/34 from 1 to F. We know the valid range is from 1 to 7.

DDRMC_PHY2/18/34 = 0x0031005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5E125E00

　DDRMC_PHY27 0x5F015E00

　DDRMC_PHY43 0x58005900

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5D865E00

　DDRMC_PHY27 0x5F005F00

　DDRMC_PHY43 0x59C05B00

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x60026100

　DDRMC_PHY27 0x60046200

　DDRMC_PHY43 0x5D505F00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x63B06000

　DDRMC_PHY27 0x62016300

　DDRMC_PHY43 0x5D405D00

DDRMC_PHY2/18/34 = 0x0032005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5F846000

　DDRMC_PHY27 0x5E205E00

　DDRMC_PHY43 0x5B415A00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5E005D00

　DDRMC_PHY27 0x5E005F00

　DDRMC_PHY43 0x580B5900

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x60486200

　DDRMC_PHY27 0x60006200

　DDRMC_PHY43 0x5D005C00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x60206100

　DDRMC_PHY27 0x60846200

　DDRMC_PHY43 0x5D505E00

DDRMC_PHY2/18/34 = 0x0033005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5E045F00

　DDRMC_PHY27 0x5D005E00

　DDRMC_PHY43 0x58285900

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5D006000

　DDRMC_PHY27 0x5E816000

　DDRMC_PHY43 0x58115B00

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x61106100

　DDRMC_PHY27 0x60426100

　DDRMC_PHY43 0x5D025E00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x61806100

　DDRMC_PHY27 0x62406300

　DDRMC_PHY43 0x5C005F00

DDRMC_PHY2/18/34 = 0x0034005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5E045F00

　DDRMC_PHY27 0x5E005F00

　DDRMC_PHY43 0x58195A00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5E005F00

　DDRMC_PHY27 0x5E805F00

　DDRMC_PHY43 0x58005A00

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x62806100

　DDRMC_PHY27 0x61006200

　DDRMC_PHY43 0x5C015E00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x62806100

　DDRMC_PHY27 0x61006200

　DDRMC_PHY43 0x5C015E00

DDRMC_PHY2/18/34 = 0x0035005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5E045F00

　DDRMC_PHY27 0x5E005E00

　DDRMC_PHY43 0x58285900

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5E085F00

　DDRMC_PHY27 0x5E045F00

　DDRMC_PHY43 0x58305B00

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x61086300

　DDRMC_PHY27 0x61206300

　DDRMC_PHY43 0x5C055E00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x62905F00

　DDRMC_PHY27 0x61016100

　DDRMC_PHY43 0x5F105E00

DDRMC_PHY2/18/34 = 0x0036005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5E015E00

　DDRMC_PHY27 0x5F205E00

　DDRMC_PHY43 0x58215A00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5D806000

　DDRMC_PHY27 0x5E046000

　DDRMC_PHY43 0x59185A00

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x61196100

　DDRMC_PHY27 0x61206200

　DDRMC_PHY43 0x5C415D00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x63306000

　DDRMC_PHY27 0x60016300

　DDRMC_PHY43 0x5E025D00

DDRMC_PHY2/18/34 = 0x0037005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5D925D00

　DDRMC_PHY27 0x5E055E00

　DDRMC_PHY43 0x5B045A00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5D846000

　DDRMC_PHY27 0x60005F00

　DDRMC_PHY43 0x58185900

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x61056200

　DDRMC_PHY27 0x60106000

　DDRMC_PHY43 0x5D035D00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x60606100

　DDRMC_PHY27 0x61006200

　DDRMC_PHY43 0x5D025D00

DDRMC_PHY2/18/34 = 0x0039005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5E045F00

　DDRMC_PHY27 0x5F005E00

　DDRMC_PHY43 0x58245800

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5E045F00

　DDRMC_PHY27 0x5F005E00

　DDRMC_PHY43 0x58245800

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x61006200

　DDRMC_PHY27 0x60506100

　DDRMC_PHY43 0x5E245D00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x60006200

　DDRMC_PHY27 0x61086300

　DDRMC_PHY43 0x5F815D00

DDRMC_PHY2/18/34 = 0x003A005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5D135E00

　DDRMC_PHY27 0x5D085E00

　DDRMC_PHY43 0x58485A00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5D846000

　DDRMC_PHY27 0x5E025E00

　DDRMC_PHY43 0x58495900

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x63206300

　DDRMC_PHY27 0x60026300

　DDRMC_PHY43 0x5D005D00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x60926000

　DDRMC_PHY27 0x61116100

　DDRMC_PHY43 0x5D805E00

DDRMC_PHY2/18/34 = 0x003B005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5D815E00

　DDRMC_PHY27 0x5E005F00

　DDRMC_PHY43 0x59005B00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5D815E00

　DDRMC_PHY27 0x5E005F00

　DDRMC_PHY43 0x59005B00

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x63436200

　DDRMC_PHY27 0x60006200

　DDRMC_PHY43 0x5C445F00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x60905F00

　DDRMC_PHY27 0x63016100

　DDRMC_PHY43 0x5F105E00

DDRMC_PHY2/18/34 = 0x003C005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5D805F00

　DDRMC_PHY27 0x5E436000

　DDRMC_PHY43 0x58105B00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5D086000

　DDRMC_PHY27 0x5D0C6000

　DDRMC_PHY43 0x58005A00

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x62106200

　DDRMC_PHY27 0x63406200

　DDRMC_PHY43 0x5D025E00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x60006000

　DDRMC_PHY27 0x61016100

　DDRMC_PHY43 0x5C105C00

DDRMC_PHY2/18/34 = 0x003D005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5E045F00

　DDRMC_PHY27 0x5E005E00

　DDRMC_PHY43 0x58285900

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5DC05E00

　DDRMC_PHY27 0x5E245F00

　DDRMC_PHY43 0x58185A00

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x62826000

　DDRMC_PHY27 0x61086300

　DDRMC_PHY43 0x5D865E00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x61806000

　DDRMC_PHY27 0x61016100

　DDRMC_PHY43 0x5E005D00

DDRMC_PHY2/18/34 = 0x003E005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5D245F00

　DDRMC_PHY27 0x5D005E00

　DDRMC_PHY43 0x58005A00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5E486000

　DDRMC_PHY27 0x5F086000

　DDRMC_PHY43 0x58005900

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x62826000

　DDRMC_PHY27 0x62016100

　DDRMC_PHY43 0x5D095E00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x61106000

　DDRMC_PHY27 0x61056200

　DDRMC_PHY43 0x5D505D00

DDRMC_PHY2/18/34 = 0x003F005A

No.28: OK (CKE is asserted)

　DDRMC_PHY11 0x5E485F00

　DDRMC_PHY27 0x5D005F00

　DDRMC_PHY43 0x58005A00

No.28: NG (CKE is not asserted)

　DDRMC_PHY11 0x5E846000

　DDRMC_PHY27 0x5D445F00

　DDRMC_PHY43 0x5A005900

No.45: OK (CKE is asserted)

　DDRMC_PHY11 0x61246200

　DDRMC_PHY27 0x62406200

　DDRMC_PHY43 0x5E025D00

No.45: NG (CKE is not asserted)

　DDRMC_PHY11 0x61105F00

　DDRMC_PHY27 0x61446000

　DDRMC_PHY43 0x5D405C00

Now, we have 8 questions.

1. If we change PHY04[DLL_WRITE_DL] value, it can affect the state of DLL lock bit?

2. Is there any peripheral that can affect the state of DLL lock bit?

You said that jitter and power supply may affect the state of DLL.

We want to know if any specific logic block or peripherals can unlock the DLL or not.

3. PHY11/27/43:[7 - 1] is RESERVED bit and these bit are always "0"?

Or any other hidden definition on bit 7 - bit 1?

4. Do you have a register which shows the lock status of Master DLL?

5. Again, if three slave DLLs are not locked at the same time, CKE can't be asserted?

6. We want to try to bypass the DLL just for our experimental purpose. (Your RM mentioned it, but we can't find any detail how to do that.)

How can we do that? We are expecting CKE always can be asserted when DLL is bypassed, because delay value is specified by us and no need to check the DLL lock status. Of course, I know DDR may not be able to work correctly with non-optimized delay value, but we can make sure that CKE is asserted in this case.

7. Could you share your result of DDRMC_PHY11/27/43 with us?

I want to see LOCK bit is always set and DLL UNLOCK state does't happen if the hardware correctly designed and configured.

I know you can't use LPDDR2 on your evaluation board, but the idea of DLL LOCK bit must be the same between DDR3 and LPDDR2.

8. Other than PHY2, is there any known or hidden registers we can change that help Master DLL lock more quickly?

We couldn't see LOCK bit on non-working handset, but on known good handset, we can see following result.

We still can see many unlocking, but known good handset shows consistent LOCK state compare to non-working handset.

If we can tweak the parameters of DLL or phase detector, we want to try it.

Handset X

After CKE is asserted:

　DDRMC_PHY11 : 0x3F043F4C : 0x63216300

　DDRMC_PHY27 : 0x3F043F50 : 0x634F6301

　DDRMC_PHY43: 0x3F043F54 : 0x5F675F01

Handset Y

After CKE is asserted:

　DDRMC_PHY11: 0x3F043F4C : 0x61606100

　DDRMC_PHY27: 0x3F043F50 : 0x62CB6201

　DDRMC_PHY43: 0x3F043F54 : 0x5EC95E01

Thanks,

Norihiro Michigami

AVNET

Re: CKE is not asserted after re-initializing DDR controller.

jiri-b36968 — Tue, 05 May 2015 14:42:56 GMT

Hello Norihiro-san,

1. No

2. affected by source clock PLL in this case. Can by unlocked on frequency change and in power mode change.

3. Should not be - no information that there is something else.

4. No. Master dll is locked and the locked value is copied to slave dlls as DLL_LOCK_VALUE. If the is anything than master DLL is locked.

5. Yes. Everything have to be locked to assert CKE.

6. If I'm not mistaken we program value 0x0001012a into PHY3,19,35 :smileyhappy:

7. TWR-VF65 DDR3 old DDR setting. going to port 9C setting into later.

8. It is not hidden - it was just documentation issue.

/Jiri

Re: CKE is not asserted after re-initializing DDR controller.

Norihiro — Wed, 06 May 2015 09:07:21 GMT

Hello Jiri-san,

Thank you for your answer. I'm updating this comment based on our latest status on May, 11th again.

Still we want to hear FSL's opinions to our questions I described in the last part of this comment.

Now we are focusing on the problem at wake-up time, rather than power-up time.

Originally, we enabled and configured PLLs , Regulators, flex-bus etc... that were _NOT_ needed for their system, immediately after wake-up.

This time, we didn't enable these unnecessary blocks or logic after wake-up. Then, DLL lock bits are locked more stably.

Based on this result, we guess that the power supply or capacity at wake-up time may be something wrong.

This is just our guess. Their system is cell phone and we are not really sure, but the power supply from their battery may not be stable.

So disabling unused block at wake-up time helped their problem.

This is our latest information based on May, 9th.

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

When we tried to change the registers like below, CKE non assertion issue was gone.

(But our sample is still not enough)

Upper 24 bit in these register are RESERVED in RM,

but we can see that these bits also have meaning when we use processor expert tool.

We think this change allows DLL to indicate LOCK status more quickly.

Of course, changing this bit may affect the reliability of LOCK status on DLL.

DDRMC_PHY03/19/35 from 0x00040404 to 0x00030404

So, our approach from now on should be,

1. Considering relaxing a condition of LOCK status by changing PHY3/19/35.

2. Considering changing the timing/sequence for enabling internal logic/block like below, to mitigate potential variation of power supply.

Enabling PLL1/2 => Configuring DDR => Enabling PLL3/4 => Configuring FLEXBUS/NFC => etc..

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

Now our question is below:

Q1) Based on Section 8.2 in our RM, we think we should check the following power planes that may affect the state of PLL or DLL.

Do you think there are any other power supply other than these power planes that we should check for this problem?

-VDD

-SDRAM_VDD2P5

-SDRAMC_VDD1P5

Q2) What do you think about our latest observation I reported above?

We want to know FSL's opinion if our observation is possible or not.

This question may be related to Q1) also,

we want to know the potential internal logic/blocks of this device that can easily affect the characteristics of DLLs.

Q3) New question I updated in 5/11.

Here is information we got from processor expert tool for DDRMC_PHY11/27/43.

Bit Field	Field	Description
31–24	Reserved	This field is reserved. This read-only field is reserved and always has the value 0.
23–16	Number of DLL lock indications must received	Specifies the number of DLL lock indications that the DLL block most receive within an 8 clock period to be considered locked. Recommend setting:0x01
15–8	Incremental interval for PHY to search for a lock	This value is the incremental interval that the PHY will use from the DLL initialization point to search for a lock. Recommended setting:0x01
7–0	DLL_START_POINT	This value is loaded into the DLL at initialization and is the value at which the DLL will begin searching for a lock. This field must be set to a value greater than or equal to 4.

If Processor Expert is correct, recommended setting for bit 23-16 should be 0x01.

In your example code for DDR3, we can see FSL sets these registers to 0x0001012a.

But for LPDDR2, FSL sets these registers to 0x00040404. We think FSL intentionally set the different values for LPDDR2 from DDR3.

Our questions is,

- Could you advise us the reason why FSL sets 0x4 to Bit 23-16 for LPDDR2?

- We want to change these bits from 0x4 to 0x3, because the problem is obviously improved with 0x3.

Is there any concern on this change?

Thanks,

Norihiro Michigami

AVNET