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.

DDR3A memory range problems with 66AK2H12

Other Parts Discussed in Thread: 66AK2H12

Hi Bill,

On our custom board, accesses to certain DDR3A memory ranges cause the 66AK2H12 to hang (and a reset or power cycle is needed to recover).   The problem memory ranges are repeatable, and occur whether accessing the memory from a DSP or ARM core.   The problem occurs on both custom boards that we've tested, though the memory ranges aren't the same on both boards.   The ranges are mainly in the upper half of the 1GB Micron DDR3 -- see attached list.   We have no problems with DDR3B memory -- it passes memory tests --  and it is using the same Micron DDR3 part number, has similar PCB routing/layout design, and is using the same DDR3 register settings as DDR3A.   We're currently working around this problem by constraining Linux to operate in the lower 256MB of DDR3A.  

Do you have any ideas for what might be causing this?  Or suggestions to try to fix it?

Note: We made progress since our previous, related postings.   For example, now we are not normally seeing any DDR3 initialization errors in PGSR0 register.   We've pulled DDR3A_REMAP_EN h/w pin 'high', and have been able to run Linux out of DDR3A (though constrained as mentioned above).

thanks,
Scott

  • Bill,    We had a discussion with Micron app engr about the above memory range issue.   While he doesn't know the details of the Keystone II memory controller, he suspected we have any issue with the timing or signal integrity of  ADDR lines.   The DQ, DQS is working for the  lower memory ranges, so he thought those weren't the issue.    He suggested we try changing the drive levels of the ADDR or CK/CK# lines (from the Keytstone II).    Is this possible to do with the DDR3 register settings?

    Please let me know, and if you have any suggestions of what might be going on.

    thanks,

    Scott

  • Scott,

    We should not need to change the drive strength.  The value currently set is appropriate for a wide range of topologies.  I expec that the problem is related to address translation.  I will request help from an expect with that configuration.

    Tom

     

  • Good news.   We added several high frequency decoupling caps between the Vtt power plane and GND for DDR3A, and we're no longer seeing the memory range issues (i.e. processor is not hanging), and the DDR3A is passing its memory tests.

    So, it would seem we had a signal integrity issue from excessive noise on the Vtt plane.

    Scott

  • Scott,

    Thanks for the update.  Glad to see that you are making progress.

    Tom