i.MX 6/7 DDR Stress Test Tool

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX 6/7 DDR Stress Test Tool

i.MX 6/7 DDR Stress Test Tool

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.

i.MX 6/7 Family DDR Stress Test 

The i.MX6/7 DDR Stress Test Tool is a PC-based software to fine-tune DDR parameters and verify the DDR performance on a non-OS, single-task environment(it is a light-weight test tool to test DDR performance). It performs write leveling, DQS gating and read/write delay calibration features.

The tool described on this page cover the following i.MX 6/7 series SoCs:

  • i.MX 6DQP (Dual/Quad Plus)
  • i.MX 6DQ (Dual/Quad)
  • i.MX 6DL/S (Dual Lite/Solo)
  • i.MX 6SoloX
  • i.MX 6SL
  • i.MX 6SLL
  • i.MX 6UL
  • i.MX 6ULL/ULZ
  • i.MX 7D/S
  • i.MX 7ULP

Note that the DDR Stress test tool supports the all of the above i.MX SoCs, however, some of the supported i.MX SoCs named in the tool support multiple i.MX SoCs as follows:

  • MX6DQ – when selected, this supports both i.MX 6DQ and i.MX 6DQP (Plus)
  • MX6DL – when selected, this supports both i.MX 6DL and i.MX 6S (i.MX 6DLS family)
  • MX6ULL – when selected, this supports both i.MX 6ULL and i.MX6 ULZ
  • MX7D – when selected, this supports both i.MX 7D and i.MX 7S

The purpose of the i.MX 6/7 series DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.). This process equips the user to then proceed with the bring-up of a boot loader and an OS. Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface.

The i.MX 6/7 series DDR Tools consist of:

There are three options to run the DDR Stress test. Each of these options are provided in the attached zip files. The following is a high-level overview of each option along with the naming convention of the associated zip file:

Option 1 GUI based:

Run the GUI executable and connect your board to the host PC via USB

  • Archive file: ddr_stress_tester_vX.xx.zip
  • The tool will first need to run a DDR initialization script for the specified i.MX SoC (refer to Load Init Script in the GUI tool).  Example initialization scripts based on NXP's development boards can be found in this zip file under the script folder.  Note, these scripts may need to be modified for your custom board and memory.

 

Option 2 DDR Stress Tester: JTAG Interface

A hardware debugger connected to the board via the JTAG interface is used to download an elf file into the i.MX SoC OCRAM (internal RAM) and then begin execution. Results are shown on the UART serial port (115200-8-n-1).

  • Archive file: ddr_stress_tester_jtag_vX.xx.zip
  • As with the GUI tool, the JTAG/debugger option will first need to run a DDR initialization script for the specified i.MX SoC. Refer to the GUI tool description above for the location of the example scripts (which are found in the ddr_stress_tester_vX.xx.zip file).
  • Note that the scripts are available either in the RealView ICE format (.inc file) or the DS-5 DSTERAM format (.ds). For other debuggers, the user will have to modify the script's command syntax for their specific debugger. This is also true if converting from a RealView Ice (.inc) format to a DS-5 DSTREAM (.ds) format and vice versa.
  • The DDR Stress Tester executable (starting with V2.20) has an auto UART detection feature. If a different UART port for the serial console has been chosen than used on the NXP development tool (EVK, SABRE) specific commands can be added to the DDR initialization script that allows you to configure for the specific UART and then load and run the elf executable. Refer to the FAQ section of this community post and the txt file found in the JTAG archive file for instructions.

 

Option 3 U-Boot:

The boot loader u-boot is running and commands in u-boot are used to download the bin file into SoC OCRAM and begin execution. Results are shown on the UART serial port (115200-8-n-1)

  • Archive file: ddr_stress_tester_uboot_vX.xx.zip
  • When downloading the DDR Stress Tool by u-boot, please copy the ddr-test-uboot-jtag-mxxxx.bin to SD card and load it to IRAM using the 'fatload' u-boot command (see notes below when using newer versions of u-boot). For i.MX6, please load the binary to 0x00907000. For i.MX7D, please load the binary to 0x00910000.  It is imperative to first disable the I and D cache in u-boot as shown below as the DDR Stress Test re-configures and re-enables the cache and MMU page table.

While this option allows the user to load and run the DDR stress test from u-boot, NXP highly recommends executing the GUI based version for system testing and debugging. The u-boot version is considered a “last resort” for systems in production which may not have USB or JTAG connectivity. The reasons behind this stance are:

  1. In the GUI version, the system starts “clean” and uninitialized, whereas u-boot initializes many SoC features outside the knowledge of the DDR stress test and may conflict with the stress test operation
  2. When running the u-boot version, the test will overwrite the contents of u-boot residing in DDR, hence the test will overwrite any data in DDR. Once the stress test is loaded and executed, u-boot itself will no longer be accessible. To return to the functionality of u-boot, a system re-boot is required.

Newer versions on u-boot do not allow a direct loading of the DDR stress test code from the SD card (boot media) directly to the SoC internal OCRAM (aka IRAM). Hence, the procedure is updated to first load the DDR stress test code into DDR and then copy into OCRAM, as shown in the procedure below:

u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000;go 0x00907000

As u-boot initializes many peripherals that may conflict with the operation of the DDR stress test, it is necessary to clock gate these peripherals prior to running the DDR stress test. Hence, it is highly recommended to augment the procedure above as follows:

u-boot> dcache off;icache off;fatload mmc 2:1 0x12000000 ddr-test-uboot-jtag-mx6dq.bin;cp.b 0x12000000 0x00907000 0x20000;
u-boot> mw 0x020c4068 0x00C0000F;
u-boot> mw 0x020c406c 0x00000000;
u-boot> mw 0x020c4074 0x3F300000;
u-boot> mw 0x020c4078 0x0000F300;
u-boot> mw 0x020c407c 0x0F000003;
u-boot> mw 0x020c4080 0x000003FC;
u-boot> go 0x00907000

Note, in the above procedure, it is recommended to write to each clock gate register in separate commands (refer to commands starting with “mw”). The SoC requires a finite amount of time to gate each clock hence performing this sequence with a new command line write ensures the SoC has time to gate the intended clocks.

 

Stress Test Revision Features Comments
3.00

Add i.MX 7ULP support in the GUI version

Known issues: USB connection is unstable when under USB HUB or some PC environments

2.92

Minor correction with write leveling calibration code error check to avoid a corner case of flagging an error when none have occurred. 

 
2.91

Resolved issue with write leveling calibration code where a race condition in the code may result in the calibration routine not being able to find any delay values.  

Only applies to MX6 series SoCs that support DDR3. 
2.90

Reserve write delay line register (MMDC_MPWRDLCTL) configuration as DDR script does when do write calibration. In previous releases, MMDC_MPWRDLCTL would be changed to 0x40404040 by default. 

 

 

* Further details available in the release notes

 _________________________________________________________________________________________________________________________________________ 

 

FAQ

 

Q. I see an error message that states "ERROR: DCD addr is out of valid range.", why is this and how do I resolve?

 

A. Sometimes, when using the register programming aid, there are registers writes that are not supported in the DCD range.  Try looking for the following items and comment them out from the DDR initialization script:

wait = on
setmem /16 0x020bc000 = 0x30 // disable watchdog (note the address for this may be different between i.MX6x devices)

 Q. How do I select the "DDR Density" pull-down menu and what is the purpose of this?

 

A. The DDR Density pull-down menu gives the user the option of testing a DDR density smaller than what they actually have on their board.  The advantage of doing this is to speed up test time to allow the user to perform a "quick test" of their system.  IMPORTANT: it is imperative that the user not set this value higher than the supported density on their board, doing so will cause the stress test to fail and/or lock up.

The DDR Density has a different meaning depending on the memory type being tested (DDR3 or LPDDR2):

For DDR3, this is the density per CHIP SELECT.  So if your board has two chip selects, and each chip select has 512MB, you would simply select 512MB or lower.  The default setting will simply set this to the detected density per chip select.

For LPDDR2, this is the density per CHANNEL.  This is only relevant for MX6 devices that support 2 channel LPDDR2 memories (MX6DQ, MX6DL).  For other MX6 devices that support only one LPDDR2 channel, then this is the total density (for the maximum setting) for that channel. Note that for LPDDR2, the number of chip selects (per channel) is irrelevant when selecting the density to test as the stress test combines both chip-selects into one combined density per channel.  For example, lets say you have a 2GB LPDDR2 device, which 2 channels and 2 chip-selects per channel.  That means you have 512MB per chip select, per channel.  Or, it also means you have 1GB per channel when combining both chip selects per channel.  In this case, you would choose (a maximum setting of) 1GB in the DDR Density drop down menu.  However, this is also the same setting as the default setting (which you are welcome to still choose 1GB to convince yourself that 1GB per channel is indeed being tested).

Now let's assume you have only one channel (LPDDR2) and one chip select, with a density of 128MB; in this case, the maximum DDR Density you can select is 128MB.

Let's assume you have one channel and two chip selects, each chip select is 128MB;  in this case, the maximum DDR Density you can select is 256MB (a combination of both chip selects).

 

Note, for the MX7D, an actual density needs to be entered. For the MX6x series, simply leaving this field as Default will cause the DDR stress test to ascertain the supported density from the DDR init script. As the MX7D DDR controller is different, this feature is not supported, hence it is required for the user to enter an actual density (for more details regarding MX7D usage of density and number of chip-selects, see the next FAQ on the DDR CS setting).

 

Q.  What is the purpose of the "DDR CS" pull-down option?

 

A.  The answer depends on which processor you are testing:

 

For the i.MX 6x series:

This pull down menu gives you the option of testing one chip select (CS0) or ALL (both) chip selects *IF* you have a two-chip select configuration.  If you have a two-chip select configuration, then this allows you to test only one chip select for faster test time; else you can choose to test both chip selects.  Note that if you have a one-chip select configuration and you choose "ALL", the stress test will return an error.

 

For the iMX 7D:

Because the MX7D DDR controller is different, the DDR stress test will need the user to supply the entire supported density found on their board. The chip select field should be left as is (0) as the test will naturally test one chip select to the next. For example, let’s assume you are using two chip selects, with each chip select being 512MB. In this case, you would enter 1GB for the DDR Density field ensuring that both chip selects will be tested. The user is allowed to enter a density less than the density found on their board (for quicker testing), but keeping in mind both chip selects may not be tested in this case.

 

Q. I run DDR calibration using the DDR Stress Test Tool to obtain the calibration results.  Are these calibration parameters are written to the uboot flash_header.S automatically or manually?

 

A. The calibration values obtained from the DDR Stress Test Tool will need to be manually updated in the flash_header.S file or any other DDR initialization script.

 

Q. When running the DDR stress test on MX7D and I try to perform calibration, I get an error stating that calibration is not supported, is this expected?

 

A. Yes, calibration is not supported or needed when using MX7.  The reason is, MX7 uses a different memory controller than the MX6 series.  The MX6 series memory controller has built-in support for calibration where the MX7 memory controller does not.

 

Q. When running the GUI version of the DDR stress test, on MX7 and I leave DDR Density as default, I get an error in the tool stating I must supply a density.  Why is this?

 

A. This is due to the fact that MX7 uses a different memory controller than the MX6 series.  In the MX6 series, it was possible to calculate the memory density from the memory controller register settings.  The MX7 memory controller is different and does not lend itself to easily calculate the supported density based on the register settings.  Instead, the user should verify the density on their board and selected this value in the DDR Density pull-down menu. 

 

Q. I noticed that when I run write-leveling calibration I sometimes see a note that due to the write-leveling calibration value being greater than 1/8 clock cycle that WALAT must be set to 1.  What does this mean?

 

A. In the MMDC chapter of the reference manual for the specific i.MX 6 device, the need to set WALAT is described in the MDMISC register as follows:

"The purpose of WALAT is to add time delay at the end of a burst write operation to ensure that the JEDEC time specification for Write Post Amble Delay (tWPST) is met (DQS strobe is held low at the end of a write burst for > 30% a clock cycle before it is released). If the value of any of the WL_DL_ABS_OFFSETn register fields are greater than ‘1F’, WALAT should be set to ‘1’ (cycle additional delay). WALAT should be further increased for any full-cycle delays added by the WL_CYC_DELn register fields."

Therefore, if the write-leveling calibration routine detects any write-leveling delay value greater than 0x1F, it will note to the user that WALAT must be set and the user should update their DDR3 init script to ensure WALAT is set.  Sometimes, a user may find that the write-leveling delay value may fluctuate from one run to the next, which is quite normal.  If it is found that this delay is "borderline" meaning sometimes it is greater than 0x1F and sometimes it might be slightly less, then it is ok to go ahead and set WALAT permanently in your init script as there is no harm in doing so and will ensure you will stay within JEDEC's tWPST.

 

Q. I sometimes see that after running write-leveling calibration that delay values being reported back are zero'd out (0x00), and then at times I see a non-zero value being reported, why is this?


A. It is quite normal to see slight variations in the delay value between write-leveling calibration runs.  The write-leveling calibration routine assumes a majority of users have designed their board such that the DDR3 memories are placed close to the i.MX 6 SoC. There’s a mechanism in NXP’s DDR Stress test write leveling calibration code that checks the returned write leveling value. If the write-leveling calibration routine detects that the returned delay value is greater than ¾ of a clock cycle, it will "zero out" the delay value. It does this because it assumes that such a large delay result is due to the fact that the DQS signal is already delayed relative to the SDCLK, and to align DQS with SDCLK requires the calibration routine to delay DQS even further to align it to the next SDCLK edge, something we ideally would like to avoid.  JEDEC specs that the DQS edge must be within 25% of a SDCLK cycle with respect to the SDCLK edge, so having DQS initially slightly delayed from SDCLK is actually ok, hence why the calibration routine “zero’s” this out when the returned value exceeds ¾ of a clock cycle.  In cases like this, the DQS edge and SDCLK edge are so close together that in some calibration runs, the DQS edge may slightly precede SDCLK (resulting in a very small write-leveling delay value) and other runs, it may be slightly delayed relative to the SDCLK (resulting in a very large write-leveling delay value that will try to align DQS to the next SDCLK edge, hence needs to be zero’d out).

 

Q. When using the JTAG version of the DDR stress test, how can I select a different UART port for my serial port?

 

A. Under the folder ddr_stress_tester_jtag_v2.52, there's a text file that describes how to add a different UART port by adding a few additional commands to your DDR init script.  The following is an outline of these commands:

1. Ungate UART module clocks (most NXP scripts ungate all of the peripheral clocks at the beginning of the script, so this part is already done)

2. Configure the IOMUX options for the pins you wish the UART to use (normally an IOMUX option for UART_TX and UART_RX, and a daisy chain option for the UART_RX input)

3. Enable the desired UART module via the register UCR1, bit UART_EN

4. Disable other UART modules (UCR1[UART_EN] = 0).  Normally disabling UART1 should be sufficient, but it doesn't hurt to disable all of the other un-used UART options for the purpose of the stress test.

 

Here's an example in the .ds file vernacular of a set up as follows: MX6DQ, UART4 on KEY_COL0 and KEY_ROW0 (assume clock is ungated to all peripherals):

mem set 0x020E01F8 32 0x00000004   #// config_pad_mode(KEY_COL0, ALT4)
mem set 0x020E01FC 32 0x00000004   #// config_pad_mode(KEY_ROW0, ALT4);
mem set 0x020E0938 32 0x00000001   #// Pad KEY_ROW0 is involved in Daisy Chain.
mem set 0x02020080 32 0x00000000   #//disable UART1 in UART1_UCR1 (Note, you can disable other UART modules as well)
mem set 0x021F0080 32 0x00000001   #//enable UART4 in UART4_UCR1

 

Here's another example in the .inc file vernacular of a set up as follows: MX6SX, UART5 on SD4_DATA4 abd SD4_DATA5 (assume clock is ungated to all peripherals):

setmem /32 0x020E0294 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA5, ALT2; UART5_TX_DATA
setmem /32 0x020E0290 = 0x2 //IOMUXC_SW_MUX_CTL_PAD_SD4_DATA4, ALT2; UART5_RX_DATA
setmem /32 0x020E0850 = 0x00000000 // IOMUXC_UART5_IPP_UART_RXD_MUX_SELECT_INPUT, daisy chain for UART5_RX input to use SD4_DATA4
setmem /32 0x021F4080 = 0x00000001 // Enable UART_EN in UCR1 of UART5

// Disable UART_EN in UCR1 of UART1, UART2, UART3, and UART4
setmem /32 0x02020080 = 0x00000000 // UART1
setmem /32 0x021F0080 = 0x00000000 // UART2
setmem /32 0x021EC080 = 0x00000000 // UART3
setmem /32 0x021E8080 = 0x00000000 // UART4

 

 

Related Resources Links:

Attachments
Comments

Hi,

I'm doing DDR calibration in iMX6UL board . My interest is to run it via JTAG. I found  "ddr-test-uboot-jtag-mx6ul.elf" from your site for the purpose.

But I'm unable to find option to flash the elf file through IAR. [Might be IAR not supporting flashing elf files into target].

can you kindly provide support by giving info on tools to flash the elf file into the target so that I can do DDR calibration.

BR,

Anantha R

Hello,

  ELF files are object ones, which are intended to be loaded and run by special loader, assuming that DRAM is

already initialized, say via a script by JTAG debugger. Since memory initialization depends on memory configuration

this should be provided by customers. Please refer to the following doc for details.

DRAM Customization on i.MX6x

  So, You should merge two functional parts (initialization and memory test) in single binary file of memory image

format and flash it, if needed, to a boot device.

Regards,

Yuri.

Hi,

We are working on custom I.MX6S board with LPDDR2 ram.

We have our beta boards, which can run the stress test tool without any problem. However, the boards of the new production cannot perform the test (using same firmware).

The only difference we found out is the iMX6 Solo revision: rev1.2 to rev1.3. Can it be the problem?

When I say the test cannot be done, I mean the program starts but afer choose the ARM core speed (both 800MHz and  1GHz) it doesn't print anything else.

The output is:

U-Boot 2015.10-00018-g784fa5c (May 26 2016 - 15:04:24 +0200)

CPU:   Freescale i.MX6SOLO rev1.3 at 792 MHz

Reset cause: POR

DRAM:  512 MiB

NAND:  128 MiB

MMC:   MMC/SD: Reset never completed.

voltage not supported by controller

In:    serial

Out:   serial

Err:   serial

Board: IMX6 - Revision B

Net:   Marvell 88E6122 - Revision 6 detected

Marvell 88E612X - Initialization delay 1798693

FEC [PRIME]

=> setenv serverip 192.168.4.139

=> tftp 0x907000 ddr-test.bin

Using FEC device

TFTP from server 192.168.4.139; our IP address is 192.168.4.188

Filename 'ddr-test.bin'.

Load address: 0x907000

Loading: #############

         546.9 KiB/s

done

Bytes transferred = 65016 (fdf8 hex)

=> icache off

=> dcache off

=> go 0x907000

## Starting application at 0x00907000 ...

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

        DDR Stress Test (2.5.2)

        Build: Mar 31 2016, 23:45:56

        Freescale Semiconductor, Inc.

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

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

        Chip ID

CHIP ID = i.MX6 Solo/DualLite (0x61)

Internal Revision = TO1.3

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

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

        Boot Configuration

SRC_SBMR1(0x020d8004) = 0x00002281

SRC_SBMR2(0x020d801c) = 0x22000001

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

What ARM core speed would you like to run?

Type 1 for 800MHz, 2 for 1GHz

ARM Clock set to 800MHz

Thank you in advance!

Michael Kjar and Mark Middleton gave a nice presentation at NXP FTF 2016 about the use of this tool for i.MX6UL and their presentation is online here:

DES-N1936 i.MX 6UltraLite DDR Tools Overview and Hardware Design Considerations.pdf

Hi,

I would like to check whether the DDR calibration stress test tool is able to provide the maximum & minimum value addition to existing optimized value?

The optimized value which obtain from averaging may not guarantee the DDR to work for wide range of temperature & boards.

If the tool can provide the maximum & minimum value together with optimized value, we can obtain the entire working range of the DDR & its working boundary.

Please share your comments.

Thank you.

Hi Robin,

The short answer is "no".

The software calibration routine could report this along with the optimized value (which I believe is the median of the range that works), but you'll still want to run the tool across a number of boards to gather statistics about how much your board-to-board variance is.


I put together a tool based on U-Boot SPL that uses a pseudo "board" that makes the process a bit simpler, by only running the calibration routine (hardware version only) and then returns to the serial boot loader:

GitHub - ericnelsonaz/u-boot at memcal-pass1


You'll need to configure it for the memory configuration and also to choose which pins are used for the serial console. There are examples for SABRE Lite, Wand, i.MXSLEVK
(configs/mx6memcal*).

Using it, you can run in a loop to get multiple samples for a board:

~/$ for n in `seq 1 100` ; do \     imx_usb SPL \ done

And since if your boards don't have pre-programmed memories, this makes it quick and easy to gather data from a set of boards after a production run.

MarekVasut​ also added dynamic calibration support that will run calibration on every boot.

[U-Boot] [PATCH 1/2] arm: imx6: Add DDR3 calibration code for MX6 Q/D/DL

Hi,

When we bypass the LDOs setting &anatop->reg_core (reg 0x20C_8140) with the following commands

set_ldo_voltage(LDO_ARM, 1500);

set_ldo_voltage(LDO_SOC, 1500);

the ddr-stress-tool hangs after printing 'ARM clock set'.

Any clues why does that happen?

Thank you

My customer may need some help
modifying scripts. 

****

Their memory is mapped and routed in a virtual identical
manner to the Sabre board, so they started with the provided script MX6DL_SabreSD_DDR3_1GB_64bit_v1.5.inc

Trying to download the script
using the GUI they get “ERROR: Can’t open USB device!!”

Their first guess is that their OTG_ID
pin (T4) is on a different IO than on the Sabre board (W23)?

*****

Hi Chester,

Do you see the device as an HID device in Device Manager (Chapter 3 of the User's manual)?

Is the device recognized by the manufacturing tool?
https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX6_L4.1.15_1.1.0_MFG_TOOL

I generally use Linux and imx_usb to load things over USB and there's a need to control permissions.
On Windows, you may also need to run as an Administrator.

I don't think the ROM boot loader will pay attention to the OTG_ID pin, but if it does, you may need to change the configuration of the DCD.

非常好的资料,谢谢!

Hi Li Chen Employee

One of customers is testing i.MX6 Dual Lite with LPDDR2.

They were able to do the stress test successfully with V1.03 tool, but with V2.52 following error comes. The tool is not selecting both Chip Selects.

“DDR CS on board is NOT compatible to your selection!”

Can you help me what could be the reason for this issue? Is this tool version specific?

The LPDDR part chosen (EDB8164B4PK-1D-F-D) is 1GB part that has 2 die, 2 CS, 2 Channel support.

Density per die/CS/Channel = 4Gb = 512MB.

  

Regards

Prakash

Hi @Prakash Bhumireddy ,

There is another ticket in community for this question.

DDR Stress Test issues - LPDDR2

B.R

Oliver

Hi all

I had customer use DDR stress test tool test i.MX6QP, the modification script SRT parameter from normal to extended will test fail, please help clearly this issue, thanks.

i.MX paltform: i.MX6QP

Stress Tester: DDR_Tester_v2.5.2.exe

Script Aid: IMX6DQP_DDR3_Script_Aid_v0.01.xlsx

pastedImage_2.png

Dear Oliver,

* I sent this question to TIC, But they recommended me to post here.

We are developing the product using i.MX7D currently.
And we have the prototype board now.

Our board uses one LPDDR3 (32 bit, 4Gb+4Gb Dual-dai/2-RANK type).

We use ddr_stress_tester_v2.52.
Because LPDDR3 which they use has two chip selects, I choose CS-ALL as the attached image, but Error is displayed in the log window and it cannot perform stress test.

pastedImage_1.png


When choosing Density-1GB and CS-0, stress_tester work fine and its result is also good.
I think that only one area of two chip selects can be tested in this condition.

How should I understand this condition?
a) Can't the stress tester handle two CS, when using LPDDR3?
b) Are we mistaken in something?

Best Regards,

George

George,

 

I saw a similar issue and here’s what I got back from the factory:

The MX7D DDR controller design is different than the DDR controller found in the MX6 series. The DDR stress test is able to parse the MX6 series DDR controller (called the MMDC) settings to ascertain things like density and number of chip selects and as such is able to distinguish one chip select from another, allowing a user to test only one chip select in a two chip select design.

 

Because the MX7D DDR controller is different, the DDR stress test will need the user to supply the entire supported density found on their board. The chip select field should be left as is (0) as the test will naturally test one chip select to the next.

 

In your case, you have 1GB total, or 512MB per chip select. When the stress test runs, as it tests the end of the first 512MB it moves onto the next 512MB, and the chip selects will automatically assert depending on which 512MB density of memory is being tested. In this case, by supplying 1GB as your density, you are ensured that both chip selects are being tested.

 

I’ll see if the factory can add this as part of the FAQ above.

 

Thanks,

Mike

Hi Michael,

Thank you for the careful description.

BR,

George

Hi all,

Does this tool i.MX6/7 DDR Stress Test Tool V2.52 also work for i.MX6S ??

If Not , what tool do you recommend?

BR,

SC

Hello

        I had raised two comments regarding IMX6 DDR3 script aid as question and I was suggested to provide those in this discussion

I would like to point two things related to DDR3 script aid for IMX6 series.

   1. The current versions of DDR3 script aid for all IMX6 series processor does not provide separate Drive strength setting for IMX6 and DDR memory which as per my understanding should be provided. Otherwise we need to change it manually when we are using different strength at IMX6 and at Memory. 

  2. Dynamic ODT is default enabled by this script aid but I think it is better to have option to enable or disable dynamic ODT. Nowhere in the script aid it is mentioned that dynamic ODT is enabled. I think this should be clearly indicated.

 

Let me know what IMX6 team thinks on above two points.

Hello Rathod,

As your comments are not related with this thread, I reply you through below thread.

Please check.

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

Hi Oliver chin, 

I am also getting the same issue what Prakash is getting.

Which is “DDR CS on board is NOT compatible to your selection!”

To solve this If I clicked the above link I get this below message.

Access to this place or content is restricted. If you think this is a mistake, please contact your administrator or the person who directed you here.

can u guide me on this.

Regards,

Vieshoth.N

Hello,

 

I have an Sabre SD board with an IMX6DL.

I run Stress Test Tool V2.52. I used file “ddr-test-uboot-jtag-mx6dl.bin”, I used uboot to load it.

 

Test runs fine, and print “DDR Stress Test is complete!“

But after that, tool is frozen. The test displays no results.

I have to restart the board.

 

If I selected "incrementing frequency", I have the same behavior.

Could you please tell me what’s wrong with test?

Regards,

Loïc

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

       DDR Stress Test (2.5.2)

       Build: Mar 31 2016, 23:45:56

       Freescale Semiconductor, Inc.

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

 

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

       Chip ID

CHIP ID = i.MX6 Solo/DualLite (0x61)

Internal Revision = TO1.1

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

 

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

       Boot Configuration

SRC_SBMR1(0x020d8004) = 0x00007040

SRC_SBMR2(0x020d801c) = 0x12000001

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

 

What ARM core speed would you like to run?

Type 1 for 800MHz, 2 for 1GHz

ARM Clock set to 800MHz

 

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

       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

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

 

Current Temperature: 40

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

 

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 7 to select this

DDR density selected (MB): 1024

 

 

Would do you want run DDR Calibration? Type 'y' to run and 'n' to skip

 

 

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 do you want run DDR Stress Test? Type 'y' to run and 'n' to skip

 

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.

400

The freq you entered was: 400

 

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

Make sure this is equal to or greater than start freq

400

The freq you entered was: 400

 

Do you want to run DDR Stress Test for simple loop or Over Night Test?

Type '0' for simple loop. Type '1' for Over Night Test

 

DDR Stress Test Iteration 1

Current Temperature: 41

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

 

DDR Freq: 396 MHz

t0.1: data is addr test

t0: memcpy10 SSN x64 test

t1: memcpy8 SSN x64 test

t2: byte-wise SSN x64 test

t3: memcpy11 random pattern test

t4: IRAM_to_DDRv2 test

t5: IRAM_to_DDRv1 test

t6: read noise walking ones and zeros test

 

DDR Stress Test is complete!

Hi,

I have some issues with the stress tool running on my custom i.MX6 board.

The application loads successfully and asks for the the ARM code speed.

Immediately after I select the core speed it gets stuck there doing nothing.

The watchdog on my board is enabled so after a couple of minutes it restarts. (not immediately after getting stuck)

I do not believe that we have something wrong in our u-boot ddr configuration because

the board works fine without known RAM problems. 

71828 bytes read in 19 ms (3.6 MiB/s)
Booting ddr test image...
## Starting application at 0x00907000 ...

============================================
DDR Stress Test (2.6.0)
Build: Oct 24 2016, 15:22:14
NXP Semiconductors.
============================================

============================================
Chip ID
CHIP ID = i.MX6 Solo/DualLite (0x61)
Internal Revision = TO1.1
============================================

============================================
Boot Configuration
SRC_SBMR1(0x020d8004) = 0x00045860
SRC_SBMR2(0x020d801c) = 0x22000013
============================================

What ARM core speed would you like to run?
Type 1 for 800MHz, 2 for 1GHz
ARM Clock set to 800MHz

I have also tried to run it on the wandboard, just to find out if it works there, and figure out if I am doing something wrong.

Running it on the wandboard everything looks OK.

=> ext2load mmc 0:2 0x00907000 ddr.bin
71828 bytes read in 124 ms (565.4 KiB/s)
=> go 0x00907000
## Starting application at 0x00907000 ...

============================================
DDR Stress Test (2.6.0)
Build: Oct 24 2016, 15:22:14
NXP Semiconductors.
============================================

============================================
Chip ID
CHIP ID = i.MX6 Solo/DualLite (0x61)
Internal Revision = TO1.1
============================================

============================================
Boot Configuration
SRC_SBMR1(0x020d8004) = 0x08003050
SRC_SBMR2(0x020d801c) = 0x22000001
============================================

What ARM core speed would you like to run?
Type 1 for 800MHz, 2 for 1GHz
ARM Clock set to 800MHz

============================================
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
============================================

....(More omitted lines) 

In my board i never see the DDR configuration lines..

Is there any reason that the application stops there ? 

Please advice,

Thank you in advance.

Hello,

Does the SCM-i.MX 6Quad require LPDDR2 calibration prior to serial download?  I'm using the SCM on a custom board and mfgtool allows Serial Downloads about 50% of the time.  The other half the time it fails.  I'm suspecting the PoPed LPDDR2 per this thread:

a problem about mfgtool in imx6q (32bit 1GB DDR) 

 

Should I instead modify the MFGtool script to configure the LPDDR2 before download.  If so, what are those register writes?

Maybe I have another problem entirely, but the boards are identically configured and are shipped with the exact same standard LPDDR2.  

Thank you,

Steve

DDR Test Tool and i.MX7S - Memory Write Problem?

I have a Warp7 board and my own custom board both with i.MX7S devices, I get the same problem when attempting a Memory Write test with both boards;

Warp7 = LPDDR3 (512 MB)

My Board = LPDDR2 (1GB)

Here is the problem;

  1. I can run DDR Calibration successfully and get calibration values (500 MHz)
  2. I can run DDR Stress Test successfully with no errors
  3. I can Read memory successfully (I see data from tests in memory)
  4. I can Write a 32bit value to memory
  5. I can see my 32 bit value just written - its correct as expected
  6. If I write another value anywhere in DDR memory it never gets saved, it reads back the original value.
  7. If I run DDR Calibration successfully again I can write one more value, then no more.

Is this a problem / bug with the DDR Test tool and i.MX7S?

Has anyone else seen this problem.

Thanks

David.

UPDATE - Now fixed by NXP  (18th Nov 2016)

Hello Oliver,

Thanks for the DDR stress tool. I was wondering if there was a specific tool for QUAD PLUS or DUAL Plus? If there is one, can you please share ?

Regards,

Manju

In V2.60 you can choose as targets: MX6DQ, MX6DL, MX6SL, MX6SX, MX6UL, MX7D and MX6ULL

Hi ,

How you ran DDR Stress test in WARP7?. i have tried using ddr_stress_tester_v2.60 tool. got error "ERROR: Can't open USB device!!!". could you please help on this. I need initializing script and test setup for this. 

Regards,

Shareena

I would also like to know this. Have you got any information?

Hi,

We are using a custom board with iMX6S, with USB boot mode, it works fine with command line DDR Stress Test Tool V1.0.3, and our .inc script file.

but it doesn't work with graphical DDR Stress Test Tool V2.60, we get the message "ERROR: Can't open USB device!!!"

can you tell us how to use this new graphical DDR Stress Test Tool V2.60 ? (maybe there is a missing library for USB port openning ?)

thank you.

note : the extension .inc have to be lowercase ".inc", with uppercase ".INC", we get "ERROR: Syntax error in script file. Please use INC or ds5 format"

I found the solution with the help of our local distributor, iMX6S is not listed in the tool, iMX6SL & iMX6SX are not compliant, but we can choose iMX6DL to test iMX6S !

Dear All, #Michael J Kjar #Craig Comberbach

I'm using ddr_stress_tester_v2.60  software for memory calibration of Alliance AS4C256M16D3A-12BCN RAM included i.MAX6 Quad processor based custom hardware design. This is the script changes for Alliance RAM.

pastedImage_1.png

1. I got following error message from software.  It says "Write leveling calibration completed, update the following registers in your initialization script " Is it possible to get 0x001F001F same calibration value for this ? Why is this happen ? 

ddr_mr1=0x00000004
Start write leveling calibration...
running Write level HW calibration
Write leveling calibration completed, update the following registers in your initialization script
MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x001F001F
MMDC_MPWLDECTRL1 ch0 (0x021b0810) = 0x001F001F
MMDC_MPWLDECTRL0 ch1 (0x021b480c) = 0x001F001F
MMDC_MPWLDECTRL1 ch1 (0x021b4810) = 0x001F001F
Write DQS delay result:
Write DQS0 delay: 31/256 CK
Write DQS1 delay: 31/256 CK
Write DQS2 delay: 31/256 CK
Write DQS3 delay: 31/256 CK
Write DQS4 delay: 31/256 CK
Write DQS5 delay: 31/256 CK
Write DQS6 delay: 31/256 CK
Write DQS7 delay: 31/256 CK

Starting DQS gating calibration
. HC_DEL=0x00000000 result[00]=0x11111111
. HC_DEL=0x00000001 result[01]=0x11111111
. HC_DEL=0x00000002 result[02]=0x11111111
. HC_DEL=0x00000003 result[03]=0x11111111
. HC_DEL=0x00000004 result[04]=0x11111111
. HC_DEL=0x00000005 result[05]=0x11111111
. HC_DEL=0x00000006 result[06]=0x11111111
. HC_DEL=0x00000007 result[07]=0x11111111
. HC_DEL=0x00000008 result[08]=0x11111111
. HC_DEL=0x00000009 result[09]=0x11111111
. HC_DEL=0x0000000A result[0A]=0x11111111
. HC_DEL=0x0000000B result[0B]=0x11111111
. HC_DEL=0x0000000C result[0C]=0x11111111
. HC_DEL=0x0000000D result[0D]=0x11111111
ERROR FOUND, we can't get suitable value !!!!
dram test fails for all values.

Error: failed during ddr calibration

Regards,

Peter.

Dear  #Oliver Chen #Michael J Kjar

Do you have any idea of getting the same value for "Write leveling calibration" as follows ?

MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x001F001F
MMDC_MPWLDECTRL1 ch0 (0x021b0810) = 0x001F001F
MMDC_MPWLDECTRL0 ch1 (0x021b480c) = 0x001F001F
MMDC_MPWLDECTRL1 ch1 (0x021b4810) = 0x001F001F

 

From where this value 0x001F001F came from ? If the test stuck in this point does that means even the processor couldn't access or write to the RAMs ? Is this a default value ? Even I tried 400MHz and 528MHz it shows the same result as above.

 

Regards,

Peter.

Hi,
We are using i.MX6 (MCIMX6Q7CVT08AC) on custom board, and the i.MX6 accesses to micron DDR3 DRAM (mt41k256m16ha).

We tried DDR Stress Test v1.0.3 on this environment,

******************************
DDR Stress Test (1.0.3) for MX6DQ
Build: Sep 18 2014, 11:11:44
Freescale Semiconductor, Inc.
******************************

and the test was failed at "t0.1: data is addr test".

-----------------------------------
loop: 543
DDR Freq: 528 MHz
t0.1: data is addr test
Address of failure: 0x103f07b0
Data was: 0x003f07b0
But pattern should match address
-----------------------------------

All boards we have produced was failed at the same test item in 2~3 days. Also all fail was caused by some bit "1" was flipped to "0". So we have tried latest Stress test,

https://community.nxp.com/docs/DOC-105652
ddr_stress_tester_uboot_v2.60.zip

but it was not failed for over 4 days.

My question is, why there is a difference between new test and old test, especially from test algorithm point of view.
We are currently concerned about Row Hammer possibility, after this Stress Test.

Recently we tried Stress Test v1.0.3 again with doubled refresh rate by changing REFR field of MMDCx_MDREF register, the loop number was improved over 1000 loops.

Thanks in advance,

Yamada

Hello,

thanks for the tool, it would be very convenient to have a linux version (even a non-graphical one), just to not have to switch back to windows for ddr calibration when setting up u-boot...

Have a nice day

Ilario

Hello,

i have i.mx6solo MCIMX6S7C with DDR3 Ram MT41K128M16.

when i try to perform DDR calibration via u-boot tool or DDR stress test the program freezes.

Please see below for the output from ddr stress test.

Does anybody know that is the problem?

Thanks!

regards,

Gerhard

> go 0x00907000

## Starting application at 0x00907000 ...

============================================
        DDR Stress Test (2.6.0)
        Build: Oct 24 2016, 15:22:46
        NXP Semiconductors.
============================================

============================================
        Chip ID
CHIP ID = i.MX6 Solo/DualLite (0x61)
Internal Revision = TO1.3
============================================

============================================
        Boot Configuration
SRC_SBMR1(0x020d8004) = 0x1b005072
SRC_SBMR2(0x020d801c) = 0x32000001
============================================

What ARM core speed would you like to run?
Type 1 for 800MHz, 2 for 1GHz
ARM Clock set to 800MHz

============================================
        DDR configuration
DDR type is DDR3
Data width: 32, bank num: 8
Row size: 15, col size: 10
Chip select CSD0 is used
Density per chip select: 1024MB
============================================

Current Temperature: 39
============================================

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
  DDR density selected (MB): 512


Would do you want to change VDD_SOC_CAP/VDD_ARM_CAP voltage? Type 'y' to run and 'n' to skip


Would do you want run DDR Calibration? Type 'y' to run and 'n' to skip


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 do you want run DDR Stress Test? Type 'y' to run and 'n' to skip

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.
400
  The freq you entered was: 400

Enter desired END freq (135 to 672 MHz), then hit enter.
Make sure this is equal to or greater than start freq
410
  The freq you entered was: 410

Do you want to run DDR Stress Test for simple loop or Over Night Test?
Type '0' for simple loop. Type '1' for Over Night Test

DDR Stress Test Iteration 1
Current Temperature: 39
============================================

I am using the stress tester tool from U-Boot.  It asks if I want to change the VDD_SOC_CAP/VDD_ARM_CAP voltage on the board.  My board is configured in bypass mode, so I don't use the internal regulators.  Do I need to set these values when running the tool in this case?  Also, what exactly is the tool doing here (changing settings on the external PMIC?)

Jared

@ Oliver Chen

Hi All,

Can we run DDR stress test tool V2.60 for multiple custom hardware design boards using only one PC ? Are there any software which can run DDR stress test for multiple boards in one time using one PC ?

Regards,

Peter.

Hi peteramond‌,

For GUI version, it can support only one PC. You can use u-boot version on multiple boards.

B.R

Oliver

I replace my board/imx6q with imx6qplus. The serial download mode can run successfully. However i.MX6/7 DDR Stress Test Tool 2.6 can't support Plus.

Is there anyone knows this? 

DDR Stress Test Tool update for IMX6QPlus ??

Thanks 

Hi there,

when I use DDR_Tester.exe tool and connect directly via usb everything works fine.

Once I use a USB Isolator (based on ADUM4160) download of init script failes without error message. the textbox clears automatically.

does anybody have an explanation or workaround for that? I need to use an USB Isolator.

thanks!

BR

Gerhard

Hello,

  use memory initialization  script specific for the i.MX6 QPlus  

Regards,

Yuri.

Hi Yuri:

I try V2.60 with my imx6qplus PCBA. I generate 64bit/528MHz script using your QPlus excel (MX6DQP DDR3 Script Aid ). It fails

Image loading...
download Image to IRAM OK

Waiting for USB SYNC packet...

Error: failed to send sync head packet

In the binary folder of ddr_stress_tester_v2.60\bin, there is no qp. I can only chose MX6DQ(ddr-test-mx6dq.bin)

Could you tell me if your ddr test tool has a update for imx6QPlus??

My customized PCBA can use imx6Q/imx6DL with your ddr test tool/script. We currently replace its CPU with imx6QPlus and it can successfully boot into serial download mode. I think CPU is running.  I just wonder if ddr_stress_tester_v2.60\bin\ddr-test-mx6dq.bin can be used for imx6Qplus.

Please advice if I need a updated DDR stress test tool. 

Thank you!

Hello,

   I checked the Stress test (under MX6DQ option) with the QP board - at least  it starts.

Regards,

Yuri.

Hi  Yuri:

 My PCBA is designed for 32bit DDR. Does IMX6QPlus support 32bit? 

 Thanks 

i.MX6QP supports 32-bit

Hello,

i have a segger flasher but dont know with wich SW i can programm the .elf on a imx6ul?

BR

Jochen

Hi All,

I am able to run DDR calibration successfully with  'i.MX6/7 DDR Stress Test Tool V2.70'. 

But my concern is blue highlighted text below. Can some one make me understand it?

What message is trying to convey?

What ever I have understood according to that, The text in orange color is failure case Is it true?


-----------------------------------
. ABS_OFFSET=0x0000007C result[1F]=0x00000011


BYTE 0:
Start: HC=0x00 ABS=0x18
End: HC=0x02 ABS=0x54
Mean: HC=0x01 ABS=0x36
End-0.5*tCK: HC=0x01 ABS=0x54
Final: HC=0x01 ABS=0x54
BYTE 1:
Start: HC=0x00 ABS=0x2C
End: HC=0x02 ABS=0x54
Mean: HC=0x01 ABS=0x40
End-0.5*tCK: HC=0x01 ABS=0x54
Final: HC=0x01 ABS=0x54

DQS calibration MMDC0 MPDGCTRL0 = 0x41540154, MPDGCTRL1 = 0x00000000

Note: Array result[] holds the DRAM test result of each byte.
0: test pass. 1: test fail
4 bits respresent the result of 1 byte.
result 01:byte 0 fail.
result 11:byte 0, 1 fail.

Starting Read calibration...

ABS_OFFSET=0x00000000 result[00]=0x11
ABS_OFFSET=0x04040404 result[01]=0x11
ABS_OFFSET=0x08080808 result[02]=0x11
ABS_OFFSET=0x0C0C0C0C result[03]=0x11
ABS_OFFSET=0x10101010 result[04]=0x01
ABS_OFFSET=0x14141414 result[05]=0x00
ABS_OFFSET=0x18181818 result[06]=0x00
ABS_OFFSET=0x1C1C1C1C result[07]=0x00
ABS_OFFSET=0x20202020 result[08]=0x00
ABS_OFFSET=0x24242424 result[09]=0x00
ABS_OFFSET=0x28282828 result[0A]=0x00
ABS_OFFSET=0x2C2C2C2C result[0B]=0x00
ABS_OFFSET=0x30303030 result[0C]=0x00
ABS_OFFSET=0x34343434 result[0D]=0x00
ABS_OFFSET=0x38383838 result[0E]=0x00
ABS_OFFSET=0x3C3C3C3C result[0F]=0x00
ABS_OFFSET=0x40404040 result[10]=0x00
ABS_OFFSET=0x44444444 result[11]=0x00
ABS_OFFSET=0x48484848 result[12]=0x00
ABS_OFFSET=0x4C4C4C4C result[13]=0x00
ABS_OFFSET=0x50505050 result[14]=0x00
ABS_OFFSET=0x54545454 result[15]=0x00
ABS_OFFSET=0x58585858 result[16]=0x00
ABS_OFFSET=0x5C5C5C5C result[17]=0x00
ABS_OFFSET=0x60606060 result[18]=0x00
ABS_OFFSET=0x64646464 result[19]=0x00
ABS_OFFSET=0x68686868 result[1A]=0x10
ABS_OFFSET=0x6C6C6C6C result[1B]=0x10
ABS_OFFSET=0x70707070 result[1C]=0x10
ABS_OFFSET=0x74747474 result[1D]=0x11
ABS_OFFSET=0x78787878 result[1E]=0x11
ABS_OFFSET=0x7C7C7C7C result[1F]=0x11

Byte 0: (0x14 - 0x70), middle value:0x42
Byte 1: (0x10 - 0x64), middle value:0x3a

MMDC0 MPRDDLCTL = 0x40403A42

Starting Write calibration...

ABS_OFFSET=0x00000000 result[00]=0x11
ABS_OFFSET=0x04040404 result[01]=0x11
ABS_OFFSET=0x08080808 result[02]=0x11
ABS_OFFSET=0x0C0C0C0C result[03]=0x11
ABS_OFFSET=0x10101010 result[04]=0x11
ABS_OFFSET=0x14141414 result[05]=0x11
ABS_OFFSET=0x18181818 result[06]=0x11
ABS_OFFSET=0x1C1C1C1C result[07]=0x11
ABS_OFFSET=0x20202020 result[08]=0x11
ABS_OFFSET=0x24242424 result[09]=0x11
ABS_OFFSET=0x28282828 result[0A]=0x10
ABS_OFFSET=0x2C2C2C2C result[0B]=0x10
ABS_OFFSET=0x30303030 result[0C]=0x10
ABS_OFFSET=0x34343434 result[0D]=0x00
ABS_OFFSET=0x38383838 result[0E]=0x00
ABS_OFFSET=0x3C3C3C3C result[0F]=0x00
ABS_OFFSET=0x40404040 result[10]=0x00
ABS_OFFSET=0x44444444 result[11]=0x00
ABS_OFFSET=0x48484848 result[12]=0x00
ABS_OFFSET=0x4C4C4C4C result[13]=0x00
ABS_OFFSET=0x50505050 result[14]=0x00
ABS_OFFSET=0x54545454 result[15]=0x00
ABS_OFFSET=0x58585858 result[16]=0x00
ABS_OFFSET=0x5C5C5C5C result[17]=0x00
ABS_OFFSET=0x60606060 result[18]=0x00
ABS_OFFSET=0x64646464 result[19]=0x00
ABS_OFFSET=0x68686868 result[1A]=0x00
ABS_OFFSET=0x6C6C6C6C result[1B]=0x00
ABS_OFFSET=0x70707070 result[1C]=0x00
ABS_OFFSET=0x74747474 result[1D]=0x00
ABS_OFFSET=0x78787878 result[1E]=0x00
ABS_OFFSET=0x7C7C7C7C result[1F]=0x00

Byte 0: (0x28 - 0x7c), middle value:0x52
Byte 1: (0x34 - 0x7c), middle value:0x58

MMDC0 MPWRDLCTL = 0x40405852


MMDC registers updated from calibration

Write leveling calibration
MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x00000000

Read DQS Gating calibration
MPDGCTRL0 PHY0 (0x021b083c) = 0x41540154
MPDGCTRL1 PHY0 (0x021b0840) = 0x00000000

Read calibration
MPRDDLCTL PHY0 (0x021b0848) = 0x40403A42

Write calibration
MPWRDLCTL PHY0 (0x021b0850) = 0x40405852


Success: DDR calibration completed!!!

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

Thanks,

Shyam

Dear @ Oliver Chen,

This is regarding imax6 processor based custom hardware design.

1)----------------------------------------------------------------------------------------------------------------------------------------------

I tried to run DDR calibration with v.2.7 and v.2.6 but it still get the following error when I click Download on GUI :

"ERROR: Write dcd failed."

But when I comment the following line of the script it run correctly.

//setmem /32 0x020c406c = 0xffffffff

What is the reason for this ?

 

One of my another custom hardware design which has same design like above I needed to comment following line to load DDR Calibration Script.

//setmem /32 0x020c4080 = 0xffffffff

What is the reason for this random issue ? 

 

2)-----------------------------------------------------------------------------------------------------------------------------------

I tried to do this memory calibration using DDR_STRESS_TESTER V1.0.2 as well. Then It occurred following problem.

 

MX6DQ opened.
HAB_TYPE: DEVELOP
rom_write: reading HAB ack failed 0x00000000
ROM Write failed, addr: 0x020c406c
Write dcd failed.

Is this related to (HAB) High Assurance Boot component ? Some issue with the processor ? 

3)----------------------------------------------------------------------------------------------------------------------------------

But 

setmem /32 0x020c406c = 0xffffffff

setmem /32 0x020c4080 = 0xffffffff

 

Are in valid address range. And some of my boards could run this script without commenting it. Why is that ? Is this some thing related to iMAX6 manufacturing ? Will they do this kind of restrictions for different batch of productions ?

Regards,

Peter

Hi peteramond‌,


I think you can create another ticket to ask questions.

Regarding your questions, I think there is something wrong with your hardware. You can modify 0x020c406c value to find th.e according bits which cause the problem. Then check hardware related to this clock

Hi,

We would like to run this on devices with HAB fuses set (imx6dl). We get the message "HAB_TYPE: PRODUCT. Not supported yet." when trying to load the binary. Any plans on adding support for this?

regards,

Emil Myhrman

No ratings
Version history
Last update:
‎12-03-2021 02:35 PM
Updated by: