IMX6Q Custom Board DDR Problem

[mccandlt]

We have a custom circuit board based on the SabreLite development board.  We are having issues getting the initial U-Boot loaded on to the system. We used the SBloader program to load the U-boot into RAM and got the following messages:

> .\sb_loader.exe -f u-boot.imx

Executed plugin successfully.

Succeed to download u-boot.imx to the device.

  Failed to run plugin u-boot.imx to the device.

From the result of sbloader we assumed that the microcontroller was operating and there was an issue with the DDR memory and we shifted our focus to verify that the DDR was functioning properly. We used the IMX.6 stress test tool located here i.MX6 DDR Stress Test Tool V1.0.3 to attempt to verify that the DDR memory was working.

Upon running the stress test program we received the following output:

>\ddr_stress_tester\DDR_Stress_Tester_V1.0.3\Binary> .\DDR_Stress_Tester.exe -t mx6x -df MX6Q_SabreSD_DDR3_register_programming_aid_v1.5.inc

MX6DQ opened.

HAB_TYPE: DEVELOP

Image loading...

download Image to IRAM OK

Re-open MX6x device.

Running DDR test..., press "ESC" key to exit.

******************************

    DDR Stress Test (1.0.3) for MX6DQ

    Build: Jun 25 2014, 12:09:21

    Freescale Semiconductor, Inc.

******************************

=======DDR configuration==========

BOOT_CFG3[5-4]: 0x00, Single DDR channel.

DDR type is DDR3

Data width: 64, bank num: 8

Row size: 14, col size: 10

Chip select CSD0 is used

Density per chip select: 1024MB

==================================

What ARM core speed would you like to run?

Type 0 for 650MHz, 1 for 800MHz, 2 for 1GHz, 3 for 1.2GHz

  ARM set to 800MHz

Please select the DDR density per chip select (in bytes) on the board

Type 0 for 2GB; 1 for 1GB; 2 for 512MB; 3 for 256MB; 4 for 128MB; 5 for 64MB; 6 for 32MB

For maximum supported density (4GB), we can only access up to 3.75GB.  Type 9 to select this

  DDR density selected (MB): 256

Calibration will run at DDR frequency 528MHz. Type 'y' to continue.

If you want to run at other DDR frequency. Type 'n'

  DDR Freq: 528 MHz

Would you like to run the write leveling calibration? (y/n)

  You have chosen not to run the write level calibration

n

Would you like to run the DQS gating, read/write delay calibration? (y/n)

  You have chosen not to run the calibration, the test will use the values in the initialization script

n

The DDR stress test can run with an incrementing frequency or at a static freq

To run at a static freq, simply set the start freq and end freq to the same value

Would you like to run the DDR Stress Test (y/n)?

y

Enter desired START freq (135 to 672 MHz), then hit enter.

Note: DDR3 minimum is ~333MHz, do not recommend to go too much below this.

333

  The freq you entered was: 333

Enter desired END freq (135 to 672 MHz), then hit enter.

Make sure this is equal to or greater than start freq

333

  The freq you entered was: 333

Beginning stress test

loop: 1

DDR Freq: 327 MHz

t0.1: data is addr test

Address of failure: 0x10000000

Data was: 0xffffffff

But pattern  should match address

It appears that the DDR is non-functional...

From there we started looking at the hardware and probing multiple signals on the board.  We noticed that the DRAM_RESET pin is low and always remains low.  This seems like it would be the very first indication we should see from the MMDC  that it is attempting to interact with the DDR memory.  We repeated the tests with 3 different boards with the same result.  We have verified that the DRAM_RESET pad is not shorted to ground and is connected to the RAM.

Is there anything that would keep the MMDC from coming out of reset?

Are there any other "Bare Metal" debugging tools available to gain insight?

I can provide more details with regard to the board or the configuration files if needed, but the board is very similar to the Sabrelite.  The U-boot and config files are the defaults from the SabreLite.  We have verified the steps above on the SabreLite and it functions properly.   

Any hints as to where to look are greatly appreciated!

[igorpadykov]

Hi mccandlt

probably some clocks/power supplies are broken/missed/or incorrect

Please check all points given in Chapter 2 "Design Checklist",

Chapter 8 "Avoiding Board Bring-up Problems"

IMX6DQ6SDLHDG  IMX6DQ6SDLHDG, Hardware Development Guide

You can start with SDK (can be run with jtag), it also has simple DDR test.

i.MX 6Series Platform SDK

Actually sabrelite board (and we do not support it) uses own bootloaders and

special methods for flashing them.

One can refer to help resources below and post issue on boundary devices forum

http://eewiki.net/display/linuxonarm/i.MX6x+SABRE+Lite+SPI+Flash+Recovery

http://boundarydevices.com/community/

Best regards

chip

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[mccandlt]

Thank you for the reply. 

We have gone through the Chapter 8 checklists and everything looks good. 

We have re-flowed and replaced the IMX6 and the RAM IC's.

We took a step back and re-examined the design checklist and verified every connection on the board.  This did lead us to one apparent error on the design.

Item #7 of Table 2-6 of IMX6DQ6SDLHDG states:

NVCC_LVDS2P5 must be powered-on even when not using the LVDS interface.

The DDR pre-drivers share the NVCC_LVDS2P5 power rail with the LVDS interface. VDDHIGH_CAP can be

utilized as the power source; tie NVCC_LVDS2P5 to VDDHIGH_CAP.

We were not using the LVDS interface and left Ball V7 (NVCC_LVDS2P5) un-connected.

My question is:

"Would this account for the behavior that we are seeing?"

We never see any response for the DRAM_RESET line or any other of the control/data lines for the DRAM.  I am assuming that without the predrive power supplied those outputs will not function at all.

Can anyone confirm that this makes sense based on the internal architecture of the controller?  We will continue to examine the design but I would feel much more comfortable re-turning the board

if I can confirm this is the expected behavior given our mistake.

Thanks in Advance!!

[igorpadykov · Accepted solution]

Hi mccandlt

yes, with NVCC_LVDS2P5 un-connected

DDR will not work with i.MX6.

Best regards

chip