i.MX6SL LPDDR2 instability

[tomrini]

Hey all.  I have a product that is heavily based on the i.MX6SL EVK.  Our currently shipping (> 100k units) make use of the MT42L256M32D2LG-25 part from Micron (which is a very slight variation on the part used on the EVK).  As this part reaches EOL next year, we're looking at the EDB8132B4PM-1D-F-D from Micron, at Micron's suggestion.  They have confirmed that this part is pin-compatible, and based on the datasheets, it should be software compatible too.  We have around 10 units with the new DDR part and all of them fail, in different ways.  We've enlisted Micron's help and they have noticed a number of JEDEC violations during the init sequence.  There's two big questions I wonder if anyone can help with.

First, while we're based on imx_v2009.08_12.10.02 I've reproduced these with imx_3.14.52_1.1.0_ga and the mx6slevk build.  One problem is that the default write value to MMDC_MDOR is not at all right (it doesn't set the values required by the JEDEC spec), the value seems to be ignored.  I've changed the value over to 0x10, but the observed wait time, both with that value and with 0x20E, is around 280 nanoseconds, not the required 200 microseconds (so we're off by a few orders of magnitude!).  The second is that any write to MMDC_MPWRCADL results in a failure to boot from SD.  What is very strange about this is that I can use imx_usb to boot these images (and Micron has as well, and measured that adding maximum delay here almost fixes some other violations that were noted).

Any ideas?  Thanks!

[tomrini · Accepted solution]

So, to fix this MDOR issue we need to use a value of 0x009F0E10 as a number of registers which claim to not be applicable to LPDDR2 need to be kept at reset value instead.  Hat tip to the engineer at Micron we've been working with that figured it out.

[raulbenetballes]

Hi,

I've suffered from the same issue as Tom, and thought I would share it for other people's benefits.

What we discovered was the all the boards we had were failing to boot, but they did at different temperatures. Initially, we thought some did work and some didn't, but in reality, it turned out that all failed to work at some temperature point. So, the ones we believe to work, were just the ones that worked at room temperatures.  Note that the important temperature here was that from the DDR device, rather than from the processor.

I can certainly confirm it had nothing to do with power supply bring up (as I could reproduce the problem in U-Boot SPL and also using the Mfg Tool download -- both doing DDR init long after power up and reset release).

Another symptom we observed was that adding a 15 us delay between the write to MMDCTL and the MR63 RESET command to the DDR made the board boot reliably (done within U-Boot SPL).

After MUCH searching, setting MDOR to 0x009F0E10 fixed our boot reliablity. More specifically, the one that made the difference was setting MDOR.tXPR to 0x9F.

Somebody at NXP needs to make sure the imximage.cfg are updated and the DDR Stress Tool and the LPDDR2 Script Aid excel spreadsheet.

Raul

[raulbenetballes]

Oh, and forgot to mention: we were using a Winbond device, with part number W97BH2KBQX2.

Layout for LP-DDR2 interface was based on i.MX6SL EVK.

[Yuri]

Hello,

   As for the erratum, according to the Errara for this issue :

"Linux BSP Status: No software workaround available" 

What about power up sequence ?

Regards,

Yuri.

[tomrini]

Yuri​, I'm not sure how to go about #1 since we're talking about the DCD script that the ROM executes first thing?  I would have assumed that the BSP releases would have addressed this issue here if applicable and we're doing the same thing.  The only difference I can spot is between what the register programming aid has which is enabling all of the clocks and the BSPs, which do not.

sinanakman​ yes, it was really just the LPDDR2 portions of MDOR I changed it to setting.  By default (based on the BSPs, that is) it was setting a bunch of the DDR3 registers and then also not setting the JEDEC value for LPDDR2.  I've actually tried even setting it to the max delay and Micron measured that there was no change here.

[sinanakman]

Hi Tom

When you mentioned that you have changed the value over to 0x10 in MMDC_MDOR and

it was ignored, just wanted to make sure that you changed  RST_to_CKE (bit 0-5) and not

SDE_to_RST (which is irrelevant for DDR2). I am working on a similar issue (but with

DDR3) and I thought I would mention this to you to verify. Perhaps you already set the

correct bits. Also, did your problem turned out to be really related to ERR007927 as

Yuri was suggesting ?

Regards

Sinan Akman

[Yuri]

Hello,

1.
  As for MMDC_MDOR - timings, controlled by this register, are based on 32 KHz clock (accuracy) and affected
by ERR007927 erratum (ROM: 32 kHz internal oscillator timing inaccuracy may affect SD/MMC and OneNAND boot).
You mentioned, that MMDC_MDOR value is ignored - this may be caused by power up sequence violation. Please

check power up sequence. 

2.
  Have You tried the recent Stress tester , and the tool, suggested by Mark ?

"i.MX6/7 DDR Stress Test Tool V2.51"

< https://community.freescale.com/docs/DOC-105652 >

“i.MX6SL LPDDR2 Register Programming Aid”

< https://community.freescale.com/docs/DOC-105968 >

Have a great day,
Yuri

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