AM3354: AM3354, DDR3 not working

Hi Linus,
Please refer to the section "Port DDR configuration if your DDR setup (devices, clock speeds, etc.) differs from the originating platform (EVM)"
software-dl.ti.com/.../U-Boot.html
Have you updated the DDR configuration in SPL for the new DDR?
Best,
-Hong

Hi Hong,

Thanks for your help.

I have updated board.c with the outcome from your EMIF spreadsheet. These are added as global structs in board.c:

static const struct ddr_data ddr3_AM335_CPNX_ddr_data = {
.datardsratio0 = 0x00000040 ,
.datawdsratio0 = 0x00000081 ,
.datafwsratio0 = 0x000000DD ,
.datawrsratio0 = 0x000000C1 ,
};

static const struct cmd_control ddr3_AM335_CPNX_cmd_ctrl_data = {
.cmd0csratio = 0x00000100 ,
.cmd0iclkout = 0x00000001 ,
.cmd1csratio = 0x00000100 ,
.cmd1iclkout = 0x00000001 ,
.cmd2csratio = 0x00000100 ,
.cmd2iclkout = 0x00000001 ,
};

static struct emif_regs ddr3_AM335_CPNX_emif_reg_data = {
.sdram_config = 0x61A05332 ,
.ref_ctrl = 0x00000618 ,
.sdram_tim1 = 0x0AAAD4DB ,
.sdram_tim2 = 0x246B7FDA ,
.sdram_tim3 = 0x50FFE67F ,
.zq_config = 0x5007858C ,
.emif_ddr_phy_ctlr_1 = 0x00100208 ,
};

const struct ctrl_ioregs ddr3_AM335_CPNX_ioregs_data = {
.cm0ioctl = 0x0000018B ,
.cm1ioctl = 0x0000018B ,
.cm2ioctl = 0x0000018B ,
.dt0ioctl = 0x0000018B ,
.dt1ioctl = 0x0000018B ,
};

And this line is called from sdram_init:

config_ddr( 400,
&ddr3_AM335_CPNX_ioregs_data,
&ddr3_AM335_CPNX_ddr_data,
&ddr3_AM335_CPNX_cmd_ctrl_data,
&ddr3_AM335_CPNX_emif_reg_data,
0 );
}

The memory from Etrontec is new for us but the one from Micron that we also tested is well known (MT41K256M16HA125E) and we used the correct timings for it.

Should I update something more for the DDR?

Thanks,

Linus

Hi Linus,
I'd agree with you that one option is to check first with new PMIC + the previous working DDR.
As you know, PMIC/DPLL/DDR are configured in very early SPL, and some relevant files:
- /board/ti/am335x/board.c
- /arch/arm/mach-omap2/am33xx/clock.c

Depending on the max speed detected in SPL code via calling am335x_get_efuse_mpu_max_freq() in board.c,
- VDD_MPU, VDD_CORE are setup via calling scale_vcores() to configure PMIC in board.c
- DPLL_MPU parameters are setup via calling get_dpll_mpu_params() in board.c, and then called by setup_dplls() in clock.c
- DPLL_DDR parameters are setup via calling get_dpll_ddr_params in board.c, and then called by setup_dplls() in clock.c
- DDR parameter structures are defined, and called by sdram_init() in board.c

Best,
-Hong

Hi Hong,

Just to clarify, we have already changed the DDR to a known type with known timings etc. The system with the known DDR behaved in the same way and the memory didn't work.

Regarding what we have done in u-boot for the new PMIC/DDR:

VDD_MPU, VDD_CORE in scale_vcores(), this does nothing since our PMIC is hardwired and doesn't talk I2C

DPLL_MPU in get_dpll_mpu_params(), this sets the freq to MPUPLL_M_1000 and return the corresponding &dpll_mpu_opp[ind][5];

DPLL_DDR in get_dpll_ddr_params, this returns &dpll_ddr3_400MHz[ind]; according to your EMIF spreadsheet tool.

DDR in sdram_init(), this runs config_ddr( 400, &ddr3_AM335xSKEVM_ioregs_data, &ddr3_AM335xSKEVM_ddr_data, &ddr3_AM335xSKEVM_cmd_ctrl_data, &ddr3_AM335xSKEVM_emif_reg_data, 0 ); according to your EMIF spreadsheet tool.

Does our changes look correct?

Thanks,

Linus

Hi Linus,
Let me loop in my colleague to get his help on DDR debugging tips...
Best,
-Hong

Linus, can you confirm the values from the EMIF spreadsheet are being programmed into the EMIF registers.  If you have JTAG, you can use the following DSS script https://git.ti.com/cgit/sitara-dss-files/am335x-dss-files/tree/am335x-ddr-analysis.dss (instructions are here https://git.ti.com/cgit/sitara-dss-files/am335x-dss-files/tree/README ) or you can dump the EMIF registers 0x4C000000-0x4C000120

Regards,

James

Thanks James,

I’ll check tomorrow and get back here.

Should I expect to find the same values as in the structs used in config_ddr(…) ?

Hi,

We have checked the values in 0x4C000000-0x4C000120 and they match with the values we set.

FYI, The design is very small so there is no JTAG on it. We dumped the registers using custom code in u-boot.

Thanks,

Linus

Linus, based on what you show, it looks like your software configuration is ok.  Just to clarify my understanding:

-this is a brand new board design which you haven't seen work yet correct?

-You have used other board designs with Micron and TPS65217 with no problem, but this board bring up with the new design with a new PMIC has not been successful?

If this is the case, and with the limited visibility on the board, i would start with the fundamentals.  Check DDR power rails for proper voltages during SPL execution, even VREF which should be half VDDQ.  

If you continually fail after a power ramp.  try powering up the board, wait for stable power rails, and issue a reset (cold or warm) if you have that capability with a push button or other means.  This will eliminate any power ramp issues if there are any

Do you see this problem across multiple boards?  Is there the possibility of an assembly issue?

Is it possible to probe CLK, CKE and/or DDR_RESET on the board?  How do these signals behave during SPL execution?

Regards,

James  

"-this is a brand new board design which you haven't seen work yet correct?"

Correct.

"-You have used other board designs with Micron and TPS65217 with no problem, but this board bring up with the new design with a new PMIC has not been successful?"

Correct, however the intended DDR for this board is from Etrontech but we had some spare Micron that we assembled to remove Etrontech as an error source.

"Do you see this problem across multiple boards? Is there the possibility of an assembly issue?"

We see this on all tested boards (4 atm), so probably not an assembly issue. However reviews of the PCB-design show various flaws that might affect the signal integrity of the ddr-signals.

I'll forward your other questions / recommendations to our EE.

From my software perspective the only lead I have is that the memory loses whats stored in it after a short time. If that can be a clue to what is going on? If not then I'll ask our EE to step in and continue the dialogue with you.

Thanks,

Linus

Hello. I am the EE and hardware designer for this project. We have discovered a critical schematic error and would like to know if this is something we can compensate for in software.

Please note that the byte lanes are swapped in the picture below:

As you can see, the polarity of the strobe pairs has been reversed. Is there some way to compensate for this in software, or does this require a complete respin?

Thank you!
Joel

Hi Joel, I'm not sure we can overcome those errors in software.

How is the data connected?  Are the data bytes also swapped going to the memory?  

If so, i can think of a couple things to try (separately)

-add 0x100 to the values in DATA0/DATA1_RD_DQS_SLAVE_RATIO and WR_DQS_SLAVE_RATIO

-set DATA0/DATA1_REG_PHY_DQ_OFFSET = 0xC0

Try both of these separately.  If the DQS polarity is 180degrees out of phase, these both are attempts to shift the differential DQS.  Although i don't know if these changes will cascade into other problems within the controller/PHY, but they are worth a try.

Regards,

James

Thanks James,

Ive tried your first suggestion, unfortunately that had no effect.

Can you advise on how to write to the DATA0/DATA1_REG_PHY_DQ_OFFSET registers? I cant find them.

Thanks,

Linus