topic Re: Bring up DDR3 Memory on Vybrid in Vybrid Processors

Bring up DDR3 Memory on Vybrid

ioseph_martinez — Mon, 24 Jun 2013 19:32:46 GMT

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

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

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?

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Tue, 25 Jun 2013 00:11:26 GMT

The two attached logs are the results for cold boot and warm reset explicitly with the default DDR3_StressTest settings that you supplied.

Cold boot failed all tests, and warm reset passed all tests. Same results for 128MB.

I already did one cold boot with my settings and it failed all tests as well.

Hopefully I'll have some answers to the other questions tomorrow.

Regards,

Russell

Re: Bring up DDR3 Memory on Vybrid

ioseph_martinez — Tue, 25 Jun 2013 17:21:40 GMT

Hi Russel,

Can you try opening a memory window? do you see zeros on the cold boot or some random data? what happens when you try to do some writes on the memory window while the cold boot? (I am trying to figure out how badly is the memory after a cold boot, I can see from the logs it fails since the first location)

I keep thinking whether this is related to a wait time we need for the memory at reset. Have you tried adding further delays during cold boot (adding break points, going step by step) I can see there is a 500us wait time after RESET is de-asserted I wonder if this is achieved.

Best Regards,

Ioseph

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Tue, 25 Jun 2013 19:13:57 GMT

Hi Ioseph,

Having a memory window open during cold boot is either giving me nothing, or crashing the debugging session. The one time there were values there, they were random seemingly random values. Any suggestions? Along the same lines, it would not let me write to a location in the memory window during cold boot.

What RESET are you referring to?

A measurement we did the other day in u-boot:

cold boot failure: after the system RESET is de-asserted, the DDR_RESET comes up ~340ms later.

warm reset success: after the system RESET is de-asserted, the DDR_RESET comes up ~40ms later.

DDRMC_CR11 (TRST_PWRON) can increase this, but nothing really decreases this on the order of ms.

Single stepping through the code does not change the behavior either.

I am seeing the same results with my timings instead of the default ones you sent, at both 316MHz and 400MHz, which are the only two values programmed in the test that fit the tCK requirement for CL6/CWL5.

Also, just to give some more information, with DEBUG turned on in u-boot, during cold boot failures the debug information would show the wrong starting address. It would be a 'random' address instead of the expected 0x80000000, but all of the other information would be identical.

e.g.

Bank #0: ff8f7f7f 4 GiB (failure)

Bank #0: ffaf7f7f 3.7 GiB (failure)

Bank #0: 80000000 256 MiB (success)

Regards,

Russell

Re: Bring up DDR3 Memory on Vybrid

anthony_huereca — Tue, 25 Jun 2013 22:24:46 GMT

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?

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Tue, 25 Jun 2013 22:33:46 GMT

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

Re: Bring up DDR3 Memory on Vybrid

ioseph_martinez — Wed, 26 Jun 2013 03:00:21 GMT

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

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Wed, 26 Jun 2013 05:42:56 GMT

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

Re: Bring up DDR3 Memory on Vybrid

ioseph_martinez — Wed, 26 Jun 2013 21:31:51 GMT

This is what I think: given the conditions which the system is failing maybe we can narrow down to the most probable causes:

- The external Memory Device is not properly initialized due conditions on cold boot

- The Vybrid device clocks/oscillator are not properly booting

Since we have seen the Vybrid is behaving OK in every aspect except DDR... I am more towards the memory is not properly initialized. But could be possible the Vybrid clocks aren't right because the oscillator problem.

Can you try the following:

- After you have initialized the memory (iomux and controller init) and try using it, can you try to initialiaze back again by calling those functions again. (modifying the code, you can use the test code I sent you)

- if that does not work, try to mimic with code, what happens from cold boot to warm reset in terms of signals to the memory device: init memory, then assert the ddr reset signal and any other thing you think necessary and try to init back again he memory.

If the above does not works, maybe we will need to look further at Vybrid system. So the following can be checked, you can start with what you think is easier...

-Switching to internal OSC and then back to external OSC. Do a short delay between flipping back to external oscillator

- Look at CKO1 bus clock and the DDR clock to make sure they look good

- Inject an external clock (ie via function generator) and see if that makes a difference (24MHz at 1.1V peak-to-peak)

Re: Bring up DDR3 Memory on Vybrid

ioseph_martinez — Wed, 26 Jun 2013 21:53:56 GMT

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

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Thu, 27 Jun 2013 00:06:58 GMT

Ioseph Martinez Pelayo wrote:

- Look at CKO1 bus clock and the DDR clock to make sure they look good

Do you mean to use CKO1 to output the DRAMC clock? Or another clock?

Craig has measured the DDR clock before during a successful boot, and said it looks good. I do not know if there is a variation during a failure.

Re: Bring up DDR3 Memory on Vybrid

ioseph_martinez — Thu, 27 Jun 2013 15:53:11 GMT

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.

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Thu, 27 Jun 2013 16:29:55 GMT

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?

Re: Bring up DDR3 Memory on Vybrid

ioseph_martinez — Thu, 27 Jun 2013 16:42:27 GMT

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?

Re: Bring up DDR3 Memory on Vybrid

ioseph_martinez — Thu, 27 Jun 2013 16:44:10 GMT

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

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Thu, 27 Jun 2013 16:53:56 GMT

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?

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Thu, 27 Jun 2013 19:04:41 GMT

Ioseph Martinez Pelayo wrote:

- After you have initialized the memory (iomux and controller init) and try using it, can you try to initialiaze back again by calling those functions again. (modifying the code, you can use the test code I sent you)

Done, same results, except DDR_CR[156] was 0x000005DC this time, instead of 0x0000055A (cold failure) or 0x0000059C (warm success).

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Thu, 27 Jun 2013 19:08:07 GMT

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.

Re: Bring up DDR3 Memory on Vybrid

rrobinson — Thu, 27 Jun 2013 19:23:01 GMT

Ioseph Martinez Pelayo wrote:

-Switching to internal OSC and then back to external OSC. Do a short delay between flipping back to external oscillator

Starting out the init with the internal OSC set followed by a delay and then setting it to the external OSC in the CCSR changed nothing. Do you think it needs to be changed in other registers as well?

Message was edited by: Russell Robinson Jr

Re: Bring up DDR3 Memory on Vybrid

melissa_hunter — Thu, 27 Jun 2013 19:23:31 GMT

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