- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
We need assistance solving problems we're having with DDR3 on a custom board using a 66AK2H12. We are getting errors in the PGSR0 register after power up, and after hard reset, for both DDR3A and DDR3B interfaces, typically reading back 0x80C00FFF or 0x80E00FFF. And, not unexpectedly, we are experiencing unstable behavior when attempting to execute out of DDR3. However, we have run several full memory tests at the Uboot level on DDR3B (when running in local ram), and it passes with no errors (writing and reading back different patterns).
Our custom board uses both of the 66AK2H12's DDR3A and DDR3B interfaces, each connected to single Micron DDR3 device, p/n MT41K256M32SLD-125 IT:E, which is an 8Gbit, x32 data, single rank, 32Meg x 32 x 8banks, capable of running upto DDR3-1600 speeds. (Note: this Micron device is a twin die consisting of two MT41K256M16 dies in a single package (where each MT41K256M16 is a 4Gbit, x16, single rank, 32 Meg x 16 x 8 banks). Therefore, it's like we're connected (fly-by arrangement) to 2 Micron MT41K256M16 devices, where the MT41K256M16 are very similar to the Samsung K4B4G1646B-HCK0 devices used on the Eval board. We are not using ECC. We have 100MHz low jitter, clock input for both DDR3A and DDR3B clock inputs.
For our board design, we followed the DDR3 termination, layout and routing guidelines (per TI DDR3 Design Requirements for KeyStone Devices Application Report), with one exception (by oversight) of not meeting the Minimum Write Level Skew (section 4.3.1.10 of the app report). Our skew is positive but much smaller than the recommended +365ps minimum skew for DDR3-1333. To work around this, we turned on the CK inverted output (PGCR0 bits 31:26 set to 010101b), but we still are getting the same errors in PGSR0.
For our testing, we initialize the DRAMs using the 'ddr3phy_1333_32' and 'ddr3_1333_32' structures copied from the EVM board's Uboot code. Also, we implement the KeyStoneII.BTS_errata_advisory.21 (DDR3 Leveling issue) using the Uboot fix in 'ddr_reset_workaround' routine.
What could be causing the PGSR0 errors, and unstable execution behavior? But why can we still pass full memory tests? Any guidance you can offer of how we might troubleshoot/solve this problem is appreciated.
thanks,
Scott
