We are currently attempting to configure an LPDDR2-chip (ISSI IS43LD16640A).
Seing as we currently work on a Linux host system, we have attempted to do the config manually, taking inspiration from the following threads:
The threads mention errors in the reference manual and internal correspondence, and does not seem to give the answer that we are looking for.
After a few failed tries, we decided that we could use Processor Expert to help us configure the LPDDR2-chips. This too was unsuccessful.
This is very hard to debug, and pinpointing single issues is next to impossible. Are there any resources, other than the Processor Expert Validation Tool, that may help us in this process? Are there any helpful people out there who knows configure this chip?
Solved! Go to Solution.
Can you try to download the new Vybrid RM and see if this helps? The DRAM controller section had a significant update and errors should have been corrected.
some code from validation board is available, but it is quite old - attached.
It would be good to check the code with latest RM (like Karina recommended - lot of changes are there). Commented here Vybrid LPDDR2 Configuration
We do not use LPDDR2 on any reference board, so the programming aid is not available.
To tune the board DDRv can be used - but changes applied in RM are not implemented here yet.
Please check timing of your memory and modify appropriate registers.
Lets go step by step:
Is DRAM controller initiated correctly? DDRMC_CR80 bit Bit
Is CKE raised? logic high on CKE output.
Can you see the DRAM clock? What is the frequency and jitter?
Can you measure shape of the signals? Need active probe for 2GHz or more.
Can you describe the design? Do you follow DDR recommendations? Trace lengths matching, stacking?
I have worked my way through the new RM (revision A8).
From the example you attached in your post (and which has been attached in several of the threads linked in my question), I notice that the function "ddr_init" write to several registers/fields labelled as "reserved" or "read only" in the RM, for example "DDR_CR039" and "DDR_CR041". These two registers are also specifically mentioned in one of my linked threads (Vybrid LPDDR2 Configuration ).
I also have some questions to specific registers:
DDRMC_CR22[TDAL] : The RM specifies a formula to use, but is not clear on what t_RP value to use. Should we use the value par bank (t_RPpb) or for all banks (t_RPab)? Also, if the DRAM datasheet specifies FAST/TYPICAL/SLOW values for t_RP (both ab and pb), which one should we then use?
DDRMC_CR24[TRP_AB] : Once again, the DRAM datasheet specifies FAST/TYPICAL/SLOW values for t_RPab. Which one should we use?
DDRMC_CR26[TREF/TRFC] : The RM does not specify whether to use t_RPab or t_RPpb. Which is it?
DDRMC_CR132[RDLAT_ADJ] : The description for this field references as community thread (https://community.freescale.com/message/562341#562341) which appear to be inaccessible.
A quick update. We are attempting to read out the DRAM in my debugger (ULinkpro D in ARM DS-5). In essence what we are doing is break during our memory test, which writes a familiar pattern (0xAA) to a pre-defined address range (starting at 0x8000_0000).
What we are seeing is that, even while stopped, the DRAM seems to be periodically changing (see attached). What may cause this?
Figure: ARM DS-5 memory view with auto-update at 1s intervals while debugger stopped at breakpoint.
there are errors in whole word - it could be anything:
- setting of DRAM controller - timing of the memory
- if it is just one byte we could talk about DQS timing.
To eliminate layout - please send me schematic, layout (at least pictures with each layer) and stacking
preparing replies for previous questions
actually I did it last week. Your stacking is correct, all traces has correct return path. Did not checked trace lengths and matching (hope you did all which is in HW user guide).
The only note I have is bypassing. We prefer to use one bigger capacitor for 2 to 3 balls than to have smaller capacitor for each ball. In your design is a lot of 22nF capacitors. But it should not be the issue.
Please correct me if I'm wrong - DRAM works for you correctly after you corrected CR73.
Thank you for your HW pointers. We will look into it.
I'm sorry if I have been unclear about CR73. The DRAM works better after correcting this register, but is still a way off from being functional.
A basic test if writing 0x55 to all bytes in the DRAM indicates that all of is accessible. We still have about 25% readback errors (every 4 byte on average).
Our main concern now is our basic addressing test. The test consist of writing the MCU-mapped DRAM address at each 4-byte boundary (i.e. 0x80000000 to 0x80000000, 0x82b4a43c to 0x82b4a43c etc) and reading back the DRAM contents for verifcation.
This seems to fail horribly, as the DRAM still seems to retain the contents from the previous test. Looking at the DS-5 memory view shows that the DRAM is filled with 0x55 (with bit-errors in between), and gradually "grows" into a new pattern consisting of a unique 4-byte pattern repeated at each 4 byte boundary where one would expect the addresses to be.
Another concern is that any attempt to read the DRAM chip-registers seems to return some of the contents of the DRAM instead.
There are no noticeable changes.
To help illustrate the issue described above, I have included a screenshot (below). The test SW has just finished testing the even data-lines and move on to testing the odd data lines. The memory view is taken from when the MCU stopped at the first readback of the odd-datalines test (no other DRAM reads have been executed after last write).
As you can see, 0xAA-pattern (with errors) is turning into the new intended pattern 0x55 as we get further away from 0x8000_0000. When refreshing the memory view, the whole memory view grows into 0x55 (without errors).
(no need to add mention in each reply - automatic notification is generated on each reply.)
Did you run any phy calibration?
It seems that you need to tune data slice 2 (CA) - DDRMC_PHY36.
I'm afraid that you are right - differential lines are swapped.
As source of confusion DRAM DS shows three different label pairs for the clock
- CK_t / CK_c
- CK / CK#
- CK / /CK
Our old validation board confirms it:
DDR_CLK0 = MCK_H0 = CK_T
/DDR_CLK0 = MCK_L0 = CK_C
From the RM:
PHY[DLL_WRITE_DLL] : SDCLK Strobe Delay. This field has no meaning in this implementation of the PHY. SDCLK strobe delay is set in field
PHY_WRLV_DL (DDRMC_PHY49 bits [23:16]). Set field to default value of 0x0 for proper operation.
How does this field need calibration if it has "no meaning"? Do you have access to information we don't?
Nevertheless, we will look into this and get back to you.