i.MX6 DDR Stress Test Tool V1.0.3

13 Kudos

Note, the tools described in this page are deprecated and are no longer maintained. For the latest maintained i.MX 6/7 series DDR tools, the user can find these here:

i.MX 6/7 Series DDR Tool Release

Hi All,

DDR_Stress_Tester is a software application for fine tuning DDR parameters and verifying DDR

performance on i.MX6 boards. It performs write leveling, DQS gating, read/write delay

calibration on the target board to match the layout of the board and archive the best DDR performance.

In addition, the stress test can help the user to verify the DDR performance on their boards.

The following are the features supported:

• Support i.MX6Q, i.MX6D, i.MX6DL, iMX6S, i.MX6SL, and i.MX6SX DDR calibration.

• Support DDR3 write leveling, DQS gating, Read/Write Delay auto-calibration.

• Support LPDDR2 Read/Write Delay auto-calibration.

• Support 16 bits, 32 bits, and 64 bits data bus.

• Support fixed-mapping 2-channel LPDDR2.

• Support DDR stress test between the frequency 135MHz and 672 MHz

If USB OTG port is not available on customer board, please use the images in DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip.

The bin files in the packages can be loaded by uboot and elf files are used by JTAG load. Please note when the image is loaded by u-boot, the DDR is initialized by u-boot (reference flash_header.S).

To run ddr stress test from u-boot, CONFIG_SPLASH_SCREEN must be disabled in u-boot. Because when enter self refresh mode in ddr stress test, DRAM access will be blocked. If splash screen in u-boot is enabled, IPU will continuously access DRAM, so the system will hang up.

If you have other DMA access in u-boot, it must be disabled.

If customer uses different RX/TX pin for UART, please contact FAE.

UART1	6DQ	6DL	6SL	6SX
TX	CSI0_DAT10/ALT3	CSI0_DAT10/ALT3	UART1_TXD/ALT0	GPIO1_IO04/ALT0
RX	CSI0_DAT11/ALT3	CSI0_DAT11/ALT3	UART1_RXD/ALT0	GPIO1_IO05/ALT0

The commands to run ddr test in i.MX6Q uboot:

U-Boot > fatload mmc 2:1 0x907000 ddr-stress-test-mx6dq.bin

U-Boot > go 0x907000

For i.MX6Q/6D 4K interleaved LPDDR2, please use version v1.0.3.1.

i.MX6 DDR Stress Test Tool V1.0.3.1 for LPDDR2 4K interleaved mode

For i.MX6/i.MX7 DDR Stress Test Tool with GUI interface, please use version V2.x:

i.MX6/7 DDR Stress Test Tool V2.10

History

V1.0.3: i.MX6SoloX is supported.

leoschwab · ‎07-21-2014

From the name, I would presume that "DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip" contained images that were intended to be loaded via JTAG and would interact over UART1. However, I've been unable to get this to work. I'm a newcomer to JTAG in general and OpenOCD in particular, so pilot error is a definite possibility.

Our board is based around the i.MX6DL. I'm using OpenOCD 0.8.0 with an Olimex USB-TINY-H. TRST on the JTAG pod is connected to JTAG_TRST; SRST is connected to POR. As such, I have reset_config set as follows:

reset_config trst_and_srst srst_pulls_trst

This appears to (mostly) work:

> reset halt
adapter speed: 1000 kHz
JTAG scan chain interrogation failed: all zeroes
Check JTAG interface, timings, target power, etc.
Trying to use configured scan chain anyway...
imx6.dap: IR capture error; saw 0x00 not 0x01
Bypassing JTAG setup events due to errors
Locking debug access failed on first, but succeeded on second try.
BUG: can't assert only SRST
Locking debug access failed on first, but succeeded on second try.
imx6.cpu.0: ran after reset and before halt ...
number of cache level 1
imx6.cpu.0 cluster 0 core 0 multi core
target state: halted
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x400001f3 pc: 0x00001080
MMU: disabled, D-Cache: disabled, I-Cache: enabled

I also appear to be able to load the image:

> load_image /home/ewhac/devel/iMX6/DDR_Stress_Tester_V1.0.3_UART1/ddr-stress-test-mx6dl.elf
82226 bytes written at address 0x00907000
downloaded 82226 bytes in 4.802489s (16.720 KiB/s)

However, after this point, I can't get anything to work. 'resume 0x907000' appears to do nothing, and subsequent 'halt' commands don't work; I have to reset. When I disassemble the loaded image from 0x907000, I see this:

> arm disassemble 0x907000 32
0x00907000     0xe59ff018     LDR r15, [r15, #0x18]
0x00907004     0xe59ff018     LDR r15, [r15, #0x18]
0x00907008     0xe59ff018     LDR r15, [r15, #0x18]
0x0090700c     0xe59ff018     LDR r15, [r15, #0x18]
0x00907010     0xe59ff018     LDR r15, [r15, #0x18]
0x00907014     0xe1a00000     NOP
0x00907018     0xe59ff014     LDR r15, [r15, #0x14]
0x0090701c     0xe59ff014     LDR r15, [r15, #0x14]
0x00907020     0x00907054     ADDEQS r7, r0, r4, ASR r0
0x00907024     0x0090703c     ADDEQS r7, r0, r12, LSR r0
0x00907028     0x00907040     ADDEQS r7, r0, r0, ASR #0x20
0x0090702c     0x00907044     ADDEQS r7, r0, r4, ASR #0x20
0x00907030     0x00907048     ADDEQS r7, r0, r8, ASR #0x20
0x00907034     0x0090704c     ADDEQS r7, r0, r12, ASR #0x20
0x00907038     0x00907050     ADDEQS r7, r0, r0, ASR r0
0x0090703c     0xeafffffe     B 0x0090703c
0x00907040     0xeafffffe     B 0x00907040
0x00907044     0xeafffffe     B 0x00907044
0x00907048     0xeafffffe     B 0x00907048
0x0090704c     0xeafffffe     B 0x0090704c
0x00907050     0xeafffffe     B 0x00907050
0x00907054     0xeb000054     BL 0x009071ac
0x00907058     0xeb00007d     BL 0x00907254
0x0090705c     0xeb00001b     BL 0x009070d0
0x00907060     0xeb00004a     BL 0x00907190
0x00907064     0xeb00005d     BL 0x009071e0
0x00907068     0xe59f02e4     LDR r0, [r15, #0x2e4]
0x0090706c     0xe321f0d1     MSR CPSR_c, 0x000000d1
0x00907070     0xe240d000     SUB r13, r0, #0x0
0x00907074     0xe321f0d2     MSR CPSR_c, 0x000000d2
0x00907078     0xe240d000     SUB r13, r0, #0x0
0x0090707c     0xe321f0d7     MSR CPSR_c, 0x000000d7

So it's pretty obvious 0x907000 is not the entry point. The ELF file says the entry point is 0x907054, and the disassembly tends to support this. However, 'resume 0x907054' has the same result (no output, unresponsive 'halt').

Just for fun, I tried 'resume 0x90703c', expecting the CPU to enter an infinite loop. But no, not even that works. It's almost as if it's ignoring my attempts to change the program counter.

What am I missing? I'm sure it's something terribly obvious...

PetrZeman · ‎07-22-2014

Hi Petr, regarding Vybrid there's not this tool but DDRV (aka DDR Validation) available within Processor Expert and Eclipse based product Driver Suite (DS) v10.4.1. You have to have installed DS v10.4 and after that you need to apply an update 1 which includes DDRV tool supported for Vybrid processors.

You may find more information about Driver Suite here - http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PE_DRIVER_SUITE. Just one note here, DDRV tool is a licensed tool, so you will need to obtain proper license to run this piece of SW. Not sure who is the right person to contact regarding DDRV licensing for Vybrid, but you may try to contact your local FSL representative for an evaluation key.

chrissie · ‎08-04-2014

Hi Grace,

The write leveling calibration result of our board is as following:

MMDC_MPWLDECTRL0 ch0 after write level cal: 0x00270021

MMDC_MPWLDECTRL1 ch0 after write level cal: 0x0030002C

MMDC_MPWLDECTRL0 ch1 after write level cal: 0x001F0030

MMDC_MPWLDECTRL1 ch1 after write level cal: 0x000F0026

I am not sure how to judge if the value is larger than 0x2f as User_Guide says:

NOTE

If write-leveling delay is larger than 0x2f, it is suggested to

set the WALAT value on MMDCx_MDMISC register to 1 in

the initialization script and re-run the DDR_Stress_Tester.

And if I should set WALAT to 1 in the script, should I set it to 1 in flash_header.S? In other words, if I calibrated a group of satisfied parameters and the stress test is also OK, should I keep flash_header.S's every register value the same as the test script.inc?

Thank you very much!

LinWang · ‎08-04-2014

Please always use WALAT=1, you can refer to below aid.

i.Mx6DQSDL DDR3 Script Aid

https://community.freescale.com/docs/DOC-94917

Sure, flash_header.s should keep same with your test script.

stevetsai · ‎08-26-2014

GraceSi,

The console port on our board is UART4. Could you release a binary file booting from SD to support UART4 console? Or could you release the source code to us to modify by ourselves? Thanks.

Steve

GraceH · ‎08-26-2014

Hi Steve,

Please contact your FAE.

Grace

leoschwab · ‎08-28-2014

Bump.

We are about to crank our new board to 1 GHz timings, and I'd like to be able to get this nailed down. The DDR3 Script Aid is very useful, but ultimately I want to use the Stress Test Tool to dial them in.

So far I've had no (apparent) success being able to run the Stress Test Tool using nothing but JTAG. This may well be because I'm not using JTAG correctly. Is there an FAQ or HOWTO somewhere that might point me in the right direction?

Also: Does setting up the DDR3 timings also set up the core clock? We'd like the ARM cores to run at 1 GHz as well; do we get that for "free" when using the output from the Script Aid?

GraceH · ‎09-22-2014

Hi Leo,

Please check whether the RX/TX pin of UART1 is same as i.MX6DL EVK, if not, the DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip or DDR_Stress_Tester_V1.0.2_UART1_for_SDboot&JTAG.zip. will not work.

please contact your FAE to build the software to configure the correct UART.

i.MX6DL UART1 :

/* UART1 TXD */

writel(ALT3, IOMUXC_SW_MUX_CTL_PAD_CSI0_DAT10);

/* UART1 RXD */

writel(ALT3, IOMUXC_SW_MUX_CTL_PAD_CSI0_DAT11);

// daisy chain setup

writel(0x1, IOMUXC_UART1_IPP_UART_RXD_MUX_SELECT_INPUT);

Grace

patrickdietrich · ‎09-25-2014

Hi there,

I'm using an i.MX6Q part on my board and I don't have OTG so I am following your instructions on loading from u-boot or JTAG.

JTAG I've had no luck so I thought I'd switch over to u-boot.

U-Boot > ext2load mmc 0:1 0x907000 ddr-stress-test-mx6dq.bin

96660 bytes read in 43 ms (2.1 MiB/s)

U-Boot > go 0x907000

## Starting application at 0x00907000 ...

then it just sits there and doesn't load anything further...

any ideas?

GraceH · ‎09-25-2014

Hi Patrick,

Are you using the binary in

DDR_Stress_Tester_V1.0.3_UART1_for_SDboot&JTAG.zip or DDR_Stress_Tester_V1.0.2_UART1_for_SDboot&JTAG.zip.

Even the name is same, but the binary files in package DDR_Stress_Tester_UART1_for_SDboot&JTAG.zip and DDR_Stress_Tester.zip are different.

In my log below, you can see the load size of ddr-stress-test-mx6dq.bin is 87520, but yours is 96660.

Another point is what I mentioned before, is the RX/TX pin of UART1 of your board same as i.MX6DQ EVK?

If not, please contact your FAE.

i.MX6DQ UART1 :

/* UART1 TXD */

writel(ALT3, IOMUXC_SW_MUX_CTL_PAD_CSI0_DAT10);

/* UART1 RXD */

writel(ALT3, IOMUXC_SW_MUX_CTL_PAD_CSI0_DAT11);

// daisy chain setup

writel(0x1, IOMUXC_UART1_IPP_UART_RXD_MUX_SELECT_INPUT);

Grace

casperli · ‎09-28-2014

hello

we test DDR3 in IMx6 solo.

we want to know if it can inclulde txpdll test by DDR3 stress test?

it appricated if any solution or suggestion

thank you for your kinldy help ^^

GraceH · ‎09-28-2014

txpdll should follow the value in datasheet of your DDR3. It is not supposed to be tested.

Grace

casperli · ‎09-28-2014

hi Grace

but if i want to tuning tXPDLL of DDR3 how can i do in iMX6 solo?

casperli · ‎09-28-2014

hello Grace

suppose it is not modified in stress test aid.

suppose txpdll is setle when DDR3 init! so how can i modify it before init??

GraceH · ‎09-28-2014

please go to

Freescale i.MX6 DRAM Port Application Guide-DDR3

Grace

casperli · ‎09-28-2014

Hello Grace

i try to modify as below

setmem /32 0x021b000c = 0x3F433F13 // MMDC0_MDCFG0

for txpdll is set a unreasonable value for DDR3 but it still test pass.

does it mean no tXPDLL related in DDR3 stress test??

Report Inappropriate Content · ‎09-28-2014

Dear Casper,

How many RAM test loop need to be completed ?

When I run the RAM stress test, it crossed around 470 loops. So whether can I consider this as Pass ?

Regards,

Azlum

casperli · ‎09-28-2014

hi Azlum

performance checking we suggest at least 500loops.

Casper

frodolai · ‎09-29-2014

I tried to test 4GB DDR3 on CS0 only and got calibration data with option "9" (maximum supported density). However, I got error on t0.1 Address of failure: 0x10000000 Data was: 0x90000000 when I set MMDC0_MDASP to 0x7F. I got error on t0.1 Address of failure: 0xc0000000 Data was: 0xffffffc0 when I set MMDC0_MDASP to 0x5F.

Is this hardware or software limitation?

leoschwab · ‎09-30-2014

I don't know how I missed this, but knowing that I could launch the DDR Stress Test tool from U-Boot would have saved us a lot of time.

GraceSi wrote:

In my log below, you can see the load size of ddr-stress-test-mx6dq.bin is 87520, but yours is 96660.

None of the binaries in the v1.0.2 or v1.0.3 ZIP files has a size of 87520 bytes. My copy of ddr-stress-test-mx6dq.bin (v1.0.3) is 96660 bytes.

Another point is what I mentioned before, is the RX/TX pin of UART1 of your board same as i.MX6DQ EVK?

If not, please contact your FAE.

i.MX6DQ UART1 :

    /* UART1 TXD */

    writel(ALT3, IOMUXC_SW_MUX_CTL_PAD_CSI0_DAT10);

    /* UART1 RXD */

    writel(ALT3, IOMUXC_SW_MUX_CTL_PAD_CSI0_DAT11);

    // daisy chain setup

   writel(0x1, IOMUXC_UART1_IPP_UART_RXD_MUX_SELECT_INPUT);

If you're successfully talking to U-Boot over UART1, then it's probably already set up correctly :-).

Currently watching the tool rotating through DDR3 clock frequencies...

casperli · ‎10-01-2014

Hello

is it possible to add in precharge power down test in Stress test??

tks ^^

casperli · ‎10-07-2014

Hello

is it possible to add in precharge power down test in Stress test??

tks ^^

GraceH · ‎10-07-2014

We don't have plan for it.

Grace

casperli · ‎10-07-2014

hello Grace

is anyway to support us to create that pattern in?

we can pay for a whole sulotion!

or who should i contact?

thanks ^^

GraceH · ‎10-07-2014

Hi Casper,

Please contact your FAE or Marketing.

Grace

markian · ‎10-20-2014

Hi Grace Si,

We are using the imx6 DDR Stress Tester both through USB OTG and loading through uboot with the SDBoot version.

We noticed in usbotg, we finish one loop in about 3minutes while the SDboot version finished in about 8minutes.

Is this expected and what is causing this time difference?

Thanks

GraceH · ‎10-21-2014

Hi Mark,

I have not see the difference you described.

i.MX6Q: L3.0.35_4.1.0 u-boot ( modification: comment out drv_lcd_init () in common/stdio.c )

DDR density selected (MB): 512

There is no difference on the time to run one loop through USB OTG and through u-boot loading, both are around 2 mins.

You can try to modify the u-boot as my changes.

Grace

markian · ‎10-21-2014

I took a look at it in more detail and the actual difference is not USB OTG vs SDBoot, it was the DDRStressTester version.

We were originally testing OSB OTG DDRStressTester v0.042, we were getting 3min for 2GB DDR there. When we started with the SDBoot, we tested with v1.0.2. which gave 8min for 2GB. When I retested v1.0.2 USB OTG, I get 8min for 2GB. Retesting for 512MB does give me the 2min you were getting.

The main items the were significantly longer in v1.0.2 was t0.1 data is addr test, t1 memcpy8 SSN x64 test, t3 memcypy11 random pattern test. What caused the drastic change in performance between v0.042 and v1.0.2?

Thanks

GraceH · ‎10-21-2014

V0.042 is not suggested for i.MX6. There are a lot of differences between v0.042 and v1.0.x.

The memory property is different.