AM335x DDR3 setup issue

Hi Marc,

This procedure is OK for DDR timing values, however you are missing the next step, which is described here: processors.wiki.ti.com/.../AM335x_DDR_PHY_register_configuration_for_DDR3_using_Software_Leveling

Hi Biser,
I have also run through the software levelling and it suggested the values and they are also configured.

I have run through the DDR setup process a number of times checking and double checking my steps but each time I get the same results in not being able to verify the memory contents.

Kind Regards
Marc

That's strange. Can you post the memory datasheet? I would like to look at the datasheet timings.

sure:
www.samsung.com/.../DS_K4B4G0846D-BC_Rev12.pdf

I have used the 800 (6-6-6) settings and the parts fitted to the board are K4B4G0846D-BCH9 rated at 1333 (9-9-9)

Kind Regards
Marc

Thanks Marc. Let me check this and I will get back to you.

Hi Biser
Thank you, I have used your timings and re-run the leveling procedure.

The gel file can now perform the write test and pass. I now need to configure u-boot.

Setting are now:
#define CMD_PHY_CTRL_SLAVE_RATIO 0x80
#define CMD_PHY_INVERT_CLKOUT 0x0

#define DATA_PHY_RD_DQS_SLAVE_RATIO 0x3D
#define DATA_PHY_FIFO_WE_SLAVE_RATIO 0x9B //RD DQS GATE
#define DATA_PHY_WR_DQS_SLAVE_RATIO 0x5A
#define DATA_PHY_WR_DATA_SLAVE_RATIO 0x8C //WRITE DATA

#define DDR_IOCTRL_VALUE (0x18B)


//******************************************************************
//EMIF parameters
//******************************************************************
// DDR3 = 400MHz

#define ALLOPP_DDR3_READ_LATENCY 0x07 //RD_Latency = (CL + 2) - 1; CL=6 for DDR3-1600 speed grade and CK of 2.5ns

#define ALLOPP_DDR3_SDRAM_TIMING1 0x0AAAE4DB
#define ALLOPP_DDR3_SDRAM_TIMING2 0x266B7FDA
#define ALLOPP_DDR3_SDRAM_TIMING3 0x501F867F

#define ALLOPP_DDR3_SDRAM_CONFIG 0x61A052B2
#define ALLOPP_DDR3_REF_CTRL 0x00000c30 //400 * 7.8us = 0xC30
#define ALLOPP_DDR3_ZQ_CONFIG 0x50074BE4


FYI I have modified the DDR spreadsheet to allow for calculation of SDRAM_CONFIG register if you think that would help other users I can make it available.

I will post back success or failure of u-boot.

Thank you for you assistance.

Kind Regards
Marc

Hi Biser,

I feel like I am now going round in circles to get this system tuned.

If I use the settings as you have defined with the system and run the tuning it will produce a set of figures and initially I was getting 0 errors with the small memory test that the AM3358_StarterKit.gel file will test.

I then later in the day use the same initialisation and can then get multiple failures and run the tuning procedure to then get 0 errors again with the memory test.

Using the calculated values in u-boot there seems to be issues with burst access with RAM as it seems to fail when performing a memset.  The system will hang.

Is there any assistance available to help in getting the system up running and stable ?

Kind Regards

Marc

Can you follow the directions here and attach the generated file:

processors.wiki.ti.com/.../How_to_use_the_AM335x_IBIS_Models

Hi Brad, here you go:

EMIF: SDRAM_CONFIG = 0x61a052b2
* Bits 26:24 (reg_ddr_term) set for RZQ/4 (001b)
* Bits 19:18 (reg_sdram_drive) set for RZQ/6 (00b)
EMIF: PWR_MGMT_CTRL = 0x00000000
DDR PHY: DDR_PHY_CTRL_1 = 0x00100007
* Bits 9:8 (reg_phy_rd_local_odt) configured as no termination (00b)
CONTROL: DDR_CMD0_IOCTRL = 0x0000018b
* Bits 9:5 control ddr_ck and ddr_ckn
- Slew slow
- Drive Strength 9 mA
* Bits 4:0 control ddr_ba0, ddr_ba2, ddr_wen, ddr_a[9:8], ddr_a[6:3]
- Slew slow
- Drive Strength 8 mA
CONTROL: DDR_CMD1_IOCTRL = 0x0000018b
* Bits 4:0 control ddr_15, ddr_a[12:10], ddr_a7, ddr_a2, ddr_a0, ddr_ba1, ddr_casn, ddr_rasn
- Slew slow
- Drive Strength 8 mA
CONTROL: DDR_CMD2_IOCTRL = 0x0000018b
* Bits 4:0 control ddr_cke, ddr_resetn, ddr_odt, ddr_csn0, ddr_[a14:13], ddr_a1
- Slew slow
- Drive Strength 8 mA
CONTROL: DDR_DATA0_IOCTRL = 0x0000018b
* Bits 9:5 control ddr_dqs1, ddr_dqsn1
- Slew slow
- Drive Strength 9 mA
* Bits 4:0 control ddr_d[15:8], ddr_dqm1
- Slew slow
- Drive Strength 8 mA
CONTROL: DDR_DATA1_IOCTRL = 0x0000018b
* Bits 9:5 control ddr_dqs0, ddr_dqsn0
- Slew slow
- Drive Strength 9 mA
* Bits 4:0 control ddr_d[7:0], dqm0
- Slew slow
- Drive Strength 8 mA
CONTROL: DDR_IO_CTRL = 0x00000000
* Bit 28 (mddr_sel) configured for SSTL, i.e. DDR2/DDR3/DDR3L operation.
CONTROL: VTP_CTRL = 0x00010167
CONTROL: VREF_CTRL = 0x00000000
CONTROL: DDR_CKE_CTRL = 0x00000001

marc murphy said:

DDR PHY: DDR_PHY_CTRL_1 = 0x00100007
* Bits 9:8 (reg_phy_rd_local_odt) configured as no termination (00b)

Two tests to try:

1. Enable ODT for reads by configuring the register to DDR_PHY_CTRL_1 = 0x00100027.  Unless you are a portable product with serious power constraints, I strongly recommend keeping this setting (or at least half thevenin ODT) permanently.
2. If that doesn't work, I recommend also increasing the read latency value, i.e. try DDR_PHY_CTRL_1 = 0x00100028.

The changing of DDR_PHY_CTRL_1=0x00100027 has made a difference when testing with the gel file and has also enabled u-boot to progress a bit more but not successfully.

I thought that increasing the value of the latency is speeding up the read ? so a latency of 6 (0x07) is the slower 400MHz and 7 (0x08) would be 606MHz . Wouldnt increasing the latency to 0x00100028 be making the interface try and read the memory too quickly ?

On this board, which is a clone of a BeagleBone Black but we have doubled the memory by using 2*4Gb *8 parts. This has been designed as a clam shell so there is one memory part on the top of the board and one on the bottom. All tracks have been tuned. Would the driving need to be different/more powerful than a single chip *16 solution ?
We also have an eMMC connected in the same way as the BBB but the device is completely blank, would this or could this also be an issue ?

marc murphy said:

The changing of DDR_PHY_CTRL_1=0x00100027 has made a difference when testing with the gel file and has also enabled u-boot to progress a bit more but not successfully.

Great!

marc murphy said:

I thought that increasing the value of the latency is speeding up the read ? so a latency of 6 (0x07) is the slower 400MHz and 7 (0x08) would be 606MHz . Wouldnt increasing the latency to 0x00100028 be making the interface try and read the memory too quickly

No, see this response:

https://e2e.ti.com/support/arm/sitara_arm/f/791/p/442397/1591515#1591515

Are there any test images that I can run that will perform a full RAM check to test from 0x80000000 to max mem?

I would like to be able to verify the complete address space.

Gel files are good but don't operate at a high bandwidth, which is where I am seeing issues.

So did ODT + increased PHY latency get things working? And now you want to stress test? Here's a stress test intended to run from Linux:

www.madsgroup.org/.../

No not every thing is working. It is stopping after the MMC initialisation part of u-boot. MLO boots and configures, u-boot is loaded to offset in RAM then starts to execute and pauses at MMC initialisation. So wanted a way to verify the ram.

You may have a hardware issue. Can you post a skew report for your DDR layout (i.e. all the signal lengths in mils)? It could also potentially relate to drive strengths for the AM335x and/or DDR, but that's much harder to debug unless you have expensive DDR validation equipment or you go through the process of simulating the interface with IBIS models.

That was most unexpected! Thanks for sharing.

Same here... we have struck the supplier off the list.