Bring up DDR3 Memory on Vybrid

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bring up DDR3 Memory on Vybrid

Jump to solution
5,604 Views
ioseph_martinez
NXP Employee
NXP Employee

Let's have the discussion here about the issues to bring up Vybrid with the DDR3 memory.

rrobinson

RossMcLuckie

melissah (just adding you so you have visibility of what is going on here)

amh

Current open questions are:

-Can you test what tests pass during a cold boot? What is the general behavior during a cold boot of the memory data (while running on iram)

-Can you test how stable is data during a cold boot? (is all dead? Like zeroes? Or you data is partially stable where some writes and reads pass and others not, you can open the memory location ax 0x80000000 to take a look) -Can you test if at cold boot lower frequencies pass?

-Can you test if at cold boot lower frequencies pass?


The DDR Stress Test will need some updates based on the memory you are using and the working configuration you have.


-Another thing I am wondering if if this cold boot issue is related to the memory controller or some wait times required to the memory to stabilize after a reset?

Tags (2)
1 Solution
3,302 Views
ioseph_martinez
NXP Employee
NXP Employee

For the record:

DDRMC_CR154 needs to be 0x682C0000

before was: 0x68200000


There was a change from Si 1.0 to 1.1. So this only affects Si 1.1 and this version requires writing this value to the register.

View solution in original post

0 Kudos
34 Replies
844 Views
rrobinson
Contributor I

Ioseph Martinez Pelayo wrote:

Using  CKO1 to observe the two clocks and check if they are fine. (BUS Clock, DDR Clock)

I would be good if there is any noticeable differences during failure.

Let me know if any of the DRAM re init techniques is of any help. I will try to take a look on the DS of the memory you are using to see if I can catch anything.

Your terminology is different than that available in the CKO1 select table. Can you please elaborate about the BUS Clock?


For BUS clock, do you mean Platform bus/PLL 2 PFD 2 (DDR CLK parent), or something else?

As for DDR Clock, Craig said that it passed compliance testing during a failed cold boot.

0 Kudos
844 Views
ioseph_martinez
NXP Employee
NXP Employee

Please take a look on the IPS Bus clock and PLL PFD 2. Although... still does not sounds like the bad 24MHz xtal start since the rest of the system sounds healthy.

0 Kudos
844 Views
rrobinson
Contributor I

Here are the clocks as measured via CKO1 right near the connector on our carrier board (first place we have access to PTB10).

0 Kudos
842 Views
ioseph_martinez
NXP Employee
NXP Employee

Both signals on cold boot and warm boot, just look fine...

0 Kudos
844 Views
rrobinson
Contributor I

I will get to that shortly.

Can you look at the differences in the PHY registers and phy_obs_reg_#_slice output in the logs I sent? Do the fact that those are different help us learn anything? Can you explain how all of that information is calculated and what would affect the change?

0 Kudos
844 Views
rrobinson
Contributor I

I also noticed that DDR_CR[156] = 0x0000059C for a warm reset and 0x0000055A for a cold boot failure. Every other register is written correctly, but this seems like the pad calibration PU/PD values are being calculated differently on cold vs warm. Thoughts?

0 Kudos
844 Views
melissa_hunter
NXP Employee
NXP Employee

Looking at the register values, the fact that the PHY11[LOCK] value is 0xFF for the cold boot (0x52 in the warm boot) is suspicious. The DLL is indicating it is locked, but looks like it is at or near the end. PHY27 and PHY43 aren't maxed out, but the LOCK value is still significantly higher than what is shown in the working case.

The difference in the pad ZQ values is prett minor when you break down the fields:

PAD_ZQ_HW_PD_RES = 0x16 vs 0x15

PAD_ZQ_HW_PU_RES = 0xE vs 0xD

Seems like a clock start issue is a possibility.

-Melissa

0 Kudos
844 Views
ioseph_martinez
NXP Employee
NXP Employee

Also checked that differences between the cold boot and warm reset logs you sent. So I tried on my board and the values are different, even between successful boots so I think is giving us little information. melissah Do you know how we can translate the info from the DLL registers status?

0 Kudos
844 Views
ioseph_martinez
NXP Employee
NXP Employee

By the way, these are the registers that have a difference: phy 11, phy 27, phy 43. Not sure if useful information can be extracted from the lock values...

0 Kudos
844 Views
ioseph_martinez
NXP Employee
NXP Employee

thinking it better, no way to control the ddr reset pin... I guess that part won't be possible to test.

0 Kudos
844 Views
anthony_huereca
NXP Employee
NXP Employee

If you hold down reset button (or the reset line if there is not a button on your board), provide power to the board, and then release reset a good amount of time after providing power, does the DDR work then on that kind of cold boot?

0 Kudos
844 Views
rrobinson
Contributor I

That is something we have checked as well, and it has the same behavior as a typical cold boot.

0 Kudos
844 Views
ioseph_martinez
NXP Employee
NXP Employee

Hi Russell, how did you ran the stress test? by loading it using uboot or directly downloading with JLINK?

0 Kudos
844 Views
rrobinson
Contributor I

I am using IAR EWB to download the code directly into iRAM using a JLink.

0 Kudos