Vybrid LPDDR2-configuration continued - IS43LD16640A

cancel
Showing results for 
Search instead for 
Did you mean: 

Vybrid LPDDR2-configuration continued - IS43LD16640A

Jump to solution
1,217 Views
Contributor V


First off, let me refer to our previous thread on this topic:

Vybrid LPDDR2-configuration - IS43LD16640A

In the thread, thanks to the excellent help of jiri-b36968 , we eventually find that the differential clocks have been swapped on our board.

We have since made a new board (still using the IS43LD16640A LPPDDR2) where the issue have been fixed, but alas still no cigar.

Our current DRAM config has been reworked based on the example configuration attached to the following thread:

https://community.freescale.com/thread/315987#367403

(File lpddr2_400mhz_golden.c.zip​, hereby referred to as "Golden")

Our test SW run from INTRAM, and contains a collection of memory tests. Our primary test follows the principals described here:

Fast Accurate Memory Test Code in C | Embedded Systems Experts

Two days ago, the tests passed on one board multiple times. The test also passed after cycling power multiple times. Other heavier tests also passed, and the DRAM config. was assume functional until the tests was run on another identical board using the same config. and failed.

We then tried to load SW into the DRAM on the functional card using the same config. This also failed.

After experimenting with the config on both boards, we eventually reached a state where no tests passed on any of the boards, even using the config. which had appeared previously functional.

We then devised a new simple tests where we simple memset(...) 1kB in the start of the DRAM, and promptly read it back, counting any errors. Test success is defined to be a run with no errors. We observed on both boards that the test failed once, but then succeed every time after that. The original tests still fail at this point.

During our rework, we found the following inconsistencies between "Golden" and the Vybrid Reference Manual (RM):

DDRMC_CR12.CASLAT_LIN : RM specifies offset at 1, but "Golden" indicates 0

DDRMC_CR34 : The RM list this field in a reserved area. "Golden" still does a write here.

DDRMC_CR38 : The RM list this register as reserved, but "Golden" still writes to it

DDRMC_CR72.ZQCS_ROTATE : RM defines val=1 as reserved, but "Golden" sets this value anyway

DDRMC_CR76.CS_EN : RM specifies val=1 as reserved. "Golden" still uses this value.

DDRMC_CR76.W2R_SPLT_EN : RM specifies val=1 as reserved. "Golden" still uses this value.

DDRMC_CR78.BUR_ON_FLY_BIT : RM specifies val=0xc as not support in lpddr2 mode. This is however the recommended value for DDR3-mode

DDRMC_CR79.CTLUPD_AREF : RM specifies this feature as "not supported by PHY", hence val=1 is reserved. "Golden" still enables it.

DDRMC_CR87.ODT_RD_MAPCS0 : DDR3 specific option (ref. RM), but "Golden" still enables it.

DDRMC_CR87.ODT_WR_MAPCS0 : DDR3 specific option (ref. RM), but "Golden" still enables it.

DDRMC_CR125 : RM specifies this as a read-only/reserved register. "Golden" still writes to it.

DDRMC_CR131 : RM specifies this as a read-only/reserved register. "Golden" still writes to it.

DDRMC_PHY50 : RM list this area as reserved, but "Golden" still writes to it.

As with other threads on Vybrid LPDDR2 configuration, there seem to be some mentions of "magic" registers, registers which are listed as read only/reserved/DDR3 only/No meaning in the RM, but still are written to. From these threads it has also become apparent that NXP employees have access to some more detailed information on the subject than what is available in the RM. This information seem to even contradict the RM at some points.

Any help to offer on the topic of Vybrid LPDDR2 configuration would be (greatly) appreciated.

Labels (1)
1 Solution
378 Views
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

View solution in original post

0 Kudos
21 Replies
379 Views
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

View solution in original post

0 Kudos
377 Views
NXP Apps Support
NXP Apps Support

tfe​ did you get previous comment?

0 Kudos
379 Views
NXP Apps Support
NXP Apps Support

Hi tfe​, jiri-b36968 is not available today  but he will continue with the  follow up next week.

0 Kudos
379 Views
Contributor V

karinavalencia​ We are still waiting for this.

/Tom

0 Kudos
379 Views
NXP Employee
NXP Employee

Hello Thomas,

I'm sorry. It is on my list. Going to check that as fast as I can.

/Jiri

379 Views
NXP Employee
NXP Employee

Hello Thomas,

checked. Bursts 4 or 8 should be supported.

please confirm: all DLLs are locked and DRAM init bit is asserted.

it is possible that timing is not correct so 4 bytes burst works and 8 not because of lost of sync.

TBST_INT_INTERVAL sets interrupt interval. But for 8 cycles IT SHOULD BE NO ISSUE, BUT TRY TO SET IT TO 0x0.

Hard to advise: there is no LPDDR2 reference board.

/Jiri

379 Views
Contributor V

My apologies on the late response. I will look into this as soon as I get the time.

379 Views
NXP Apps Support
NXP Apps Support

jiri-b36968​ do you have an update?

0 Kudos
379 Views
Contributor V

jiri-b36968​ / karinavalencia

Please confirm that NXP continue to follow up this thread.

/Tom

0 Kudos
379 Views
Contributor V

jiri-b36968​​ / karinavalencia​,

Any follow-up coming soon?

0 Kudos
379 Views
NXP Apps Support
NXP Apps Support

jiri-b36968​ please continue with the follow up.

0 Kudos
379 Views
Contributor V

We got the DRAM to work, by setting burst length to 4 (was 8). Hence we finally do have something working.

Next we are wondering why burst length 8 doesn't work, and why burst length 4 do work?

Edit: Forgot to mention that we also changed the DRAM burst interrupt intervals in addition to that mentioned above.

/Tom

0 Kudos
379 Views
NXP Employee
NXP Employee

Hello Thomas,

all DLLs have to be locked prior to any other setting. And they have to be lock at the same time to finish init sequence. They can occasionally unlock and then lock back quickly. Is bit [8] set which indicates correct init? Do you see CKE assertion?

try go up to 0x00730104. If not locked you have to improve board design and minimize noise.

/Jiri

0 Kudos
379 Views
Contributor V

This seem to help.

However, we find that our memory tests still fail. On occasion, after attempting to load our SW into DRAM, the following two interrupts were raised in CR80:

Bit [2] - Multiple accesses outside the defined PHYSICAL memory space have occurred.

Bit [1] - A memory access outside the defined PHYSICAL memory space has occurred.

Here are some relevant registers:

CR83[OORAD] = 0x2AA22C0A

CR84 = 0x28310101

CR84[OORLEN] = 0x01

CR84[OORTYP] = 0x01

CR84[OORID] = 0x2831

Loading SW into INTRAM, and writing to the DRAM address-range using the debugger seem to work fine, but our memory tests still seem to fail. Our address test report that some address bits seem "stuck" (see Fast Accurate Memory Test Code in C | Embedded Systems Experts ).

0 Kudos
379 Views
Contributor V

An update:

After some testing, we have reached a point where all our memory tests pass. Yet we are unable to load any SW into DRAM using the ULINKpro D debugger in ARM DS-5.

We noticed that bit 24 in DDRMC_CR80[INTSTAT] keep asserting. Even after clearing it in DDRMC_CR81[INT_ACK], it still asserts.

The RM describes this interrupt as: "A state change has been detected on the dfi_init_complete signal after initialization."

The RM does not have any other information on this signal. Neither does the DRAM chip datasheet or the JEDEC Standard (JESD209-2B).

What might cause this?

0 Kudos
379 Views
NXP Employee
NXP Employee

Hello Thomas,

dfi_init_complete signal indicates that physical part of DRAM interface has been initiated correctly. After that whole MC init flag should be asserted. It is bit[8].

If bit[24] is asserted it means that physical part was initiated but something happened after correct initiation - like DLL unlock.

Please check state of PHY11/27/43. All DLLs should be locked.

/Jiri

0 Kudos
379 Views
Contributor V

Hi Jiri,

After checking PHY11/27/43, we found that th DLLs indeed do loose their lock.

We poll bit24 of CR80[INT_STAT], every 500ms or so, and clear the bit in CR[INT_ACK] if has been asserted, as explained above. Addionally, we have added a check for the DLL locks, and print the DDRMC_PHY11/27/43[DLL_UNLOCK_VALUE] if the lock is missing.

It seems that the locks for the data slices 1,2,3 does not have to be missing at the same time. Indeed, typically only two locks are missing simultaneously, but the lock value remains fairly constant for each data slice at around 0x40 for all slices.

The following post suggest that CR105 and CR110 are meaningful with LPDDR2, despite the RM stating the obvious.

Vybrid LPDDR2 Configuration

With this in mind, I attempted Software Gate Training described in RM (ch. 10.1.6.16.3 in rev.8), without any significant results.

Thoughts?

/Tom

0 Kudos
379 Views
Contributor V

By the way, here is the .ds-file we use to configure the DRAM:

VybridLpddr2.ds - Pastebin.com

/Tom

0 Kudos
379 Views
NXP Employee
NXP Employee

Hello Thomas,

fist of all please change PHY03/19/35 (DLLs setting)

     memory set 0x400AE40C 0 0x00040404    # DDRMC_PHY03

     ..

     ..

to for example 0x004301xx  (you can start with 0x002301xx to 0x005301xx)

/Jiri

0 Kudos
379 Views
Contributor V

jiri-b36968​, I would like to stress that our memory tests do pass on occasion. In these instances, all tests pass until power has been cycled a few times. However, for the most part, the tests fail.

As of yet, we are unable to load any SW into DRAM.

/Tom

0 Kudos