Vybrid LPDDR2-configuration - IS43LD16640A

cancel
Showing results for 
Search instead for 
Did you mean: 

Vybrid LPDDR2-configuration - IS43LD16640A

Jump to solution
2,868 Views
tfe
Contributor V

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:

VF5xx / Example of LPDDR2 Configuration

Re: Executing from LPDDR2

Vybrid LPDDR2 Init

Vybrid LPDDR2 Configuration

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?

Labels (3)
1 Solution
727 Views
CommunityBot
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
34 Replies
728 Views
CommunityBot
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
606 Views
karina_valencia
NXP Apps Support
NXP Apps Support

Hi Thomas,

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.

Regards,

Karina V

606 Views
jiri-b36968
NXP Employee
NXP Employee

Hello Tomas,

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[8]

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?

/Jiri

0 Kudos
606 Views
tfe
Contributor V

Hi Jiri,

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.

Thanks.

/Tom

0 Kudos
606 Views
tfe
Contributor V

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?

/Tom

memview.gif

Figure: ARM DS-5 memory view with auto-update at 1s intervals while debugger stopped at breakpoint.

0 Kudos
606 Views
jiri-b36968
NXP Employee
NXP Employee

Hello Thomas,

there are errors in whole word - it could be anything:

- setting of DRAM controller - timing of the memory

- layout

- 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

/Jiri

606 Views
tfe
Contributor V

Hi jiri-b36968

I am still awaiting a response from you on the layout/schematics.

What is your verdict?

/Tom

0 Kudos
603 Views
jiri-b36968
NXP Employee
NXP Employee

Hello Thomas,

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.

/Jiri

603 Views
tfe
Contributor V

Hi jiri-b36968

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.

/Tom

0 Kudos
603 Views
jiri-b36968
NXP Employee
NXP Employee

Hi Thomas,

just one blind shoot.

Please modify to

PHY_MASTER_CTRL   0x0023012a

was 0x0001012a.

it is used in PHY03 / 19 / 35

/Jiri

0 Kudos
603 Views
tfe
Contributor V

Hi jiri-b36968

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).

/Tom

Screenshot from 2015-12-10 11_50_13.png

0 Kudos
603 Views
jiri-b36968
NXP Employee
NXP Employee

Hi Tom,

(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.

/Jiri

603 Views
tfe
Contributor V

Hi Jiri,

We have looked into this. There seem to be no change when varying the above-mentioned parameters.

/Tom

0 Kudos
603 Views
karina_valencia
NXP Apps Support
NXP Apps Support

jiri-b36968​ please  continue with the  follow up.

0 Kudos
603 Views
karina_valencia
NXP Apps Support
NXP Apps Support

jiri-b36968​ any comment?

0 Kudos
603 Views
jiri-b36968
NXP Employee
NXP Employee

Hello Karina,

the customer's board arrived in the office. Tests/tuning  are planned to the end of January (not standard support)

/Jiri

603 Views
karina_valencia
NXP Apps Support
NXP Apps Support

jiri-b36968​ based o your previous comment this case can be closed?

0 Kudos
603 Views
jiri-b36968
NXP Employee
NXP Employee

Hi Karina,

no we cannot close it so far :smileyhappy:. have customer's board on my desk - just started testing as planed.

/Jiri

0 Kudos
603 Views
jiri-b36968
NXP Employee
NXP Employee

Hello Thomas,

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

DRAM DS:

pastedImage_0.png

Vybrid DS

pastedImage_1.png

Our old validation board confirms it:

DDR_CLK0 = MCK_H0 = CK_T

/DDR_CLK0 = MCK_L0 = CK_C

Memory:
pastedImage_4.png

Vybrid:
pastedImage_5.png

pastedImage_6.png

/Jiri

603 Views
tfe
Contributor V

Hi Jiri,

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.

/Tom

0 Kudos