First off, let me refer to our previous thread on this topic:
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:
(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:
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.
Solved! Go to Solution.
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.
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.
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  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.
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  - Multiple accesses outside the defined PHYSICAL memory space have occurred.
Bit  - 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 ).
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?
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.
If bit 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.
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.
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.
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-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.