This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x DDR3 Ratio Seed Question

I just have a question that I am hoping someone will be able to clarify.  Basically i have one board of 10 that does not seem to operate properly with the DDR3 values found using the following method:

http://processors.wiki.ti.com/index.php/AM335x_DDR_PHY_register_configuration_for_DDR3_using_Software_Leveling

All 10 were working wonderfully for weeks now then i decided to move my speed from 303MHz to 400MHz.  After doing this i redid all the timing values and reran the leveling procedure.  9 of 10 worked fine after this, but the 10th was not functioning properly.  I found if i changed the CMDX_REG_PHY_CTRL_SLAVE_RATIO  from 0x80 (which was the value given to my by the RatioSeed spreadsheet) to 0x40 then my last board works too.  So I was looking into the reason for this and noticed in the RatioSeed spreadsheet this value is calculated by the following:

If PHY_INVERT_CLKOUT = 1 Then 0x100 Else 0x80

Then when i look in the TRM i notice this register says it can only have a value from 0 to 0x80.  

So is there an error in either the TRM or in the ratio spreadsheet? According to the TRM this number is used to generate a ratio of 256ths so it would make sense that it could goto 0x100, but the values column says otherwise.  Plus i have that board that doesn't work with it set to 0x80 making me almost think the ratio spreadsheet should be:

If PHY_INVERT_CLKOUT = 1 Then 0x80 Else 0x40

I don't know though, I guess I don't fully understand what this value does and I'm just trying to figure out why changing it allows all my boards to function properly.

  • Hi Jarrod,

    I will ask the factory team to check this.

  • HI Biser,

    I have same question.
    Can the CMDX_REG_PHY_CTRL_SLAVE_RATIO set to 0x100?


    I think so, too. "If PHY_INVERT_CLKOUT = 1 Then 0x80 Else 0x40"


    Best Regards,
    Taka
  • Jarrod and Taka,
    first, there is a typo in the TRM. The value has a range 0-100h. We will get this fixed.

    Second, this value should just be either 0x80 or 0x100 depending on the invert_clk value, as designated in the ratio seed spreadsheet. If you are getting 0x40 to work on some boards, there is some other underlying issue that is not correct.

    A couple of questions:
    -What are the values that you are inputting into the spreadsheet?
    -What are the results of the software leveling?
    -what software are you using to initialize the DDR (u-boot, starterware, GEL)?
    -are you changing CTRL_SLAVE_RATIO after running s/w leveling, or using 0x40 when performing s/w leveling?
    -What's your DDR topology (# of memories, point to point, T topology, fly by, etc.)?

    Regards,
    James
  • James,

    Thanks for the response!  I was thinking it was a typo since the rate could store a 10-bit value, just made me curious since 0x40 worked for me.  I used the 0x40 in my software leveling will the GEL file and the software leveling .out file.  I also use 0x40 in U-Boot.  Here are my register values from U-Boot:

    #define MT41J256M16HA125_EMIF_READ_LATENCY	0x00100007	
    #define MT41J256M16HA125_EMIF_TIM1			0x0AAAD4DB	
    #define MT41J256M16HA125_EMIF_TIM2			0x266B7FDA	
    #define MT41J256M16HA125_EMIF_TIM3			0x501F867F	
    #define MT41J256M16HA125_EMIF_SDCFG			0x61C052B2	
    #define MT41J256M16HA125_EMIF_SDREF			0x00000C30	
    #define MT41J256M16HA125_ZQ_CFG				0x50074BE4	
    #define MT41J256M16HA125_DLL_LOCK_DIFF		0x1			
    #define MT41J256M16HA125_RATIO				0x40		
    #define MT41J256M16HA125_INVERT_CLKOUT		0x0			
    #define MT41J256M16HA125_RD_DQS				0x3C		
    #define MT41J256M16HA125_WR_DQS				0x37		
    #define MT41J256M16HA125_PHY_WR_DATA		0x70		
    #define MT41J256M16HA125_PHY_FIFO_WE		0x97		
    #define MT41J256M16HA125_IOCTRL_VALUE		0x18B		

    Here are my entries from the timing configuration tool to get the TIMX registers:

    Memory datasheet symbol Memory Datasheet value unit
    tCK 2.5 ns
    tRP 13.75 ns
    tRCD 13.75 ns
    tWR 15 ns
    tRAS  35 ns
    tRC 48.75 ns
    tRRD 4 tCK
    tWTR 4 tCK
    tXP 3 tCK
    ODTLon 3 tCK
    tXS 270 ns
    tXSDLL 512 tCK
    tRTP 4 tCK
    tCKE 3 tCK
         
    tZQCS 64 tCK
    tRFC 260 ns
    tREFI    
    tRASmax    

    And here are my seed values:

    DDR Clock Frequency: 400MHz

    PHY_INVERT_CLKOUT:  0

    DDR_CK Trace Length:  1.044868, 1.044868

    DDR_DQSx Trace Length:  0.915049, 0.7985965

    It gave me these as seeds:

    DATAx_PHY_RD DQS_SLAVE_RATIO:  x40

    DATAx_PHY_FIFO_WE_SLAVE_RATIO:  x72

    DATAx_PHY_WR DQS_SLAVE_RATIO: x3

    CMDx_PHY_CTRL_SLAVE_RATIO:  0x80

    But i had to change the slave ratio to 0x40 for some of my boards.  Some worked fine with the 0x80, but all of them worked with the 0x40.  The resulting software leveling values can be seen in my u-boot parameters above, that is what they were.  Also all boards worked fine with 0x80 when i was running at 333MHz as well.  So maybe some issue with some of those boards, but curious that 0x40 makes them all work fine : /.

    Oh also there is only one DDR3 RAM Chip on the board.  It is a Micron MT41J256M16HA-125.  Let me know if you need any more information or if you have more information for us!

    Thanks,

    Jarrod

  • Jarrod Cook said:
    #define MT41J256M16HA125_DLL_LOCK_DIFF 0x1

    Set that to 4 (i.e. the hardware default).  That register actually should not be programmed at all.  I think all boards should work with 0x80 with this new configuration.  I think you need to re-run your leveling with this change.

  • Brad,

    Thanks for the response!  I will make this change and give it a try.  I will need to finish up some stuff and then get my hands on a group of boards so i can find one that doesn't work with 0x80 at 400MHz so i can verify this will fix it, so probably a week or 2 before i can test it out.  It is weird though that the U-Boot from PSP v6.00.00 that I used has this value set to 1 for a bunch of the different RAMs it defines in arch/arm/include/asm/arch-am33xx/ddr_defs.h.  That is why i have it set to 1 i simply used one of the ones in ddr_defs.h already and modified it for my RAM.

    Thanks,

    Jarrod

  • Jarrod Cook said:
    It is weird though that the U-Boot from PSP v6.00.00 that I used has this value set to 1 for a bunch of the different RAMs it defines in arch/arm/include/asm/arch-am33xx/ddr_defs.h.

    FYI, that was fixed over 2 years ago in u-boot:

    commit 39245c8699c68f85a5aaa3153d954370920d09c0
    Author: Tom Rini <trini@ti.com>
    Date:   Thu Nov 7 11:42:57 2013 -0500

        am33xx: Stop modifying certain EMIF4D registers