Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

2Gb DDR3/DDR3L Issues

Hey All,

Has any one gotten the DM8169 to work with 4 Micron MT41J128M16JT-125 or  MT41K128M16JT-125 parts (2 parts per EMIF for 1GByte total)?  We're having some erratic behavior and I'm not sure if it is an assembly issue or a timing issue caused by incorrect DDR3 configuration.   I'm pretty sure the layout and board fabrication are ok (it's a long story).  If you have, can you post the DDR settings from your GEL file?

To add a level of complication to the whole thing we couldn't get the standard DDR3 "J" parts so we installed DDR3L MT41K128M16JT-125 parts instead.  It looks like the DDR3L parts should be completely compatible but any thoughts on that would be welcomed as well.

Any and all help/comments/suggestions are greatly appreciated!

Thanks,

Roz

  • Hi Roz,
     
    Have you gone through the steps described in this link: http://processors.wiki.ti.com/index.php/DM816x_C6A816x_AM389x_DDR3_Init
     
    Best Regards
    Biser
  • Biser,

    I looked through this but it specifically states:

    Important Note: SW leveling process is not intended to diagnose a non-working DDR interface. It is only intended for fine tuning the DDR PHY when the DDR interface is functionally working.

    and since the DDR is not working I figured this wasn't going to help us.

    -Roz


  • Roz,

    What is the exact behavior? When you access the DDR is it resulting in a Data/Prefetch abort? Or, are you seeing incorrect values only?

  • Renjith,

    It looks like writes are ok but reads are sporadic.  On the one board I was able to quantify the behavior, it appears that byte 2 (bits 16-23) occasionally reads data tied to the next location up.  I think the bytes getting corrupted are the last byte in a burst but this is only conjecture.  If we fill the next address up with the same value in bits 16-23 then no read error occurs on that byte.  The other bytes appear to work correctly.  Unfortunately, I was not able to confirm this same behavior on our other boards because our JTAG debugger died right before I could test it (when it rains - it pours!).  A new debugger should arrive Friday and I plan on trying to quantify the exact behavior on a second board.

    Our test procedure was to load the GEL file with the DDR settings and then just open a memory window with auto-refresh enabled.  We could then see when bytes changed since they turned red.  We added a fill feature in the GEL file so we could test different data patterns.

    -Roz

  • Roz,

    When the calibration is not proper, you'll see corrupted values from DDR. Suppose if your DDR parameters are configured correctly, and if the calibration is wrong you'll see corrupted values with successful reads. So, you are seeing this with respect to byte-lane2 (16-23) alone. So I suspect that your DDR leveling parameters are not optimal. 

    Can you run the DDR leveling algorithm once and verify the seed values once again?

  • Renjith,

    Thanks.  I'll run the algorithm once I have a debugger and can test it (probably on Friday).  I'll let you know what I find.  Thanks for all your help!

    -Roz

  • Renjith,

    We got our debugger today and three new boards.  It turns out we were battling a board fab/rework/assembly problem on one of the original boards and marginal timing on the other that was somehow introduced by the rework of removing the original DDR and putting new parts down.  I was able to get one of the original boards working with improved DQS ration parameters.  The new boards came up right away but the improved DQS numbers can only help so those are what we are using going forward.  Thanks for you insight!

    Roz

  • Renjith,

    That should have read "DQS ratio" not 'ration'!  You should never "ration" your DQS settings!  Thanks again,

    Roz

  • Roz,

    You should always be generous while using DQS settings :) Can you mark this query as answered, if you think so?