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
Solved! Go to 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
jiri-b36968 could you take this, please?
Vilem
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
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
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
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
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
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?
===============================
Register dump from System (a)
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
Register dump from System (b)
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.
Register dump from known good system (c)
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
Register dump from known good system (d)
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
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
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
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
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
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
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
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
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
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
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
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
Hello Norihiro-san,
AQ1: Yes. PLL lock and also PFD stable are important. Same as DLL lock. PLLs are powered from main 1.2V. Focus on power ripple here (ripple have to be <5% of Vcc)
AQ2: It makes sense. If you turn off rest of the system then noise is reduced. Power supply is more stable. DLL is more stable.
AQ3:
There is some misinterpretation here - please check.
PHY 11/27/43:
Meaning of PHY 11/27/43 is:
There are three slave DLLs. DDR3 uses two. LP-DDR2 uses three (also data slice 2).
This is information from DLL - no reason to write into it.
PHY03/19/35: Master control
We set 0x0001012a into PHY03/19/35 (not PHY 11/27/43) where 2a is starting point of DLL.
Other bits sets Master DLL:
0x __XXXX____ sets number if LOCK indications to consider as LOCKED. It is not recommended to change this field.
0x ______XX__ sets time to DLL to lock. It can help to lock - bigger value = more time. It is not recommended to change this field.
0x ________XX sets DLL starting point.
PHY 02/18/34: Slave control
We set 0x00210000
bits 21-17 RD_DL_SET read delay setting recommended 0x4 (0b100)
bits 18-16 DLL_PH_DETECTS_SEL DLL Phase detect selector (0b001)
more elements can improve DLL lock.
/Jiri
Hello Norihiro-san,
one more think.
Investigating if e6235 could have influence.
Please check PLL lock and PFDx_STABLE bits of used PLLs for DDRC and CA5.
Please send me the customer's clock configuration.
CA5 clock source , DDRC clock source:
CCM_CCSR:
- CA5_CLK_SEL
- DDRC_CLK_SEL
- if SYS_DIV_OUT_CLK which source or PFD.
ANADIG setting of used PLL
/Jiri