Bring up DDR3 Memory on Vybrid

[ioseph_martinez]

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?

[rrobinson]

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

[antoniojenkins]

Where did you get the tool to do this?

[antoniojenkins]

Specifically, "the default DDR3_StressTest settings that you supplied".  Seems this would be a nice tool to have for anyone setting up ddr3 on vybrid.

[Nouchi]

Hello,

I'm testing my own Vybrid design, your DDR3_StressTest seems to be very interesting for me. Is it possible to have this code?

Best regards,

Emmanuel

[ioseph_martinez]

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

[rrobinson]

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

[ioseph_martinez]

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)

[rrobinson]

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

[ioseph_martinez]

Based on your other results, 24MHz oscillator start up seems healthy; so probably is not the slow start of this one...

Can you try configure the DDR_RESET pin iomux with pull down? (to keep the memory part during reset)

can you try to use a bigger value on DDR_CR11? datasheet from the memory says at least wait 500us before cke becomes active. (would not explain why it works after warm resets...)

wonder if this can be of any help.

[rrobinson]

Both of those changes do not change the outcome, either individually or together. I can use a CR11 < 500us (i.e. your settings, which set it to about 200us), or greater than 500us, and there is no change. Fails cold boot; succeeds with warm reset

[ioseph_martinez]

Thanks Russell for all measurements and tests. I will query internally with the Vybrid team including HW members to see if they can come up with any other ideas.

[rrobinson]

Hi Ioseph,

Do you have any new information for us?

Thanks,

Russell

[ioseph_martinez]

Sorry Russell, still reviewing it with the team, I will get back you later on.

[karina_valencia]

Hi ioseph_martinez do you have an update on this case?

[ioseph_martinez]

Hi Karina,

For the moment we are checking this case internally with Phytec.

We are going to receive some boards from them test.

Best Regards,

Ioseph

[karina_valencia]

Thank  Ioseph for let us know.

[ioseph_martinez · Accepted solution]

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.

[rrobinson]

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

[rrobinson]

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.

[ioseph_martinez]

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.