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

No ratings

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

Hello,

We are working on custom I.MX6DL board with LPDDR2 ram. We are genarating dram script with "i.Mx6DQSDL LPDDR2 Script Aid"

, but testing this script with u-boot needs script transformation to DCD and rebuilding. I takes too much time. We are wondering that can we able to test LPDDR script( output of i.Mx6DQSDL LPDDR2 Script Aid ) with i.MX6/7 DDR Stress Test Tool V2.00 tool?

Is there any way to understand the LPDDR2 script is correct and is ready to use in u-boot?

Hi,

We tried the tool on our custom i.MX6DL board, but we are receiving an error :" Failed to send calibration command". We also get a similar error when we start DDR test. What would be possible causes?

Hi AK,

Yes. You can use V2.00 tool with your own script.

1. select MX6DL target cpu and other option according to your board

2. load your own script

3. download and do DDR calibration

There is no script file need if you are use u-boot, because u-boot can initial DDR controller itself. You can modify u-boot to initial DDR controller registers. If u-boot can access DDR memory correctly, we can assume the value you write to DDR controller is OK.

Did you use DDR stress tester tool V1.03 or earlier version with the same script? If you get good result by the older version, I think there are some bugs in V2.00. If not, I think you have a incorrect initial script and i.MX6DL hung up.

With V1.0.3 our script functions ok.

Hi Sir,

Is it can support LPDDR2 Interleave mode ?

We saw those message

BOOT_CFG3[5-4]: 0x02, 4K Interleaved enabled. Not supported by this tool currently.

DDR type is LPDDR2 in 1-channel mode.

Can you update ?

Hi Sir,

The GUI-based V2.0 DRAM stress test tool, I found some settings conflict with target i.MX.

For example:

if the target chip is i.MX6UL,  ARM speed options are 800MHz, 1GHz and 1.2GHz still. But, Cortex A7 ARM in i.MX6UL operates of  speeds up to 528Mhz only. We cannot find the such option in V2.00 tool. I suggest all available options should be limited to target i.MX selection.

Best regards,

Carl

Hi, Sir

     I just use this tester and it report below error on my board.

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

        DDR configuration

DDR type is LPDDR2 in 1-channel mode.

Data width: 32, bank num: 8

Row size: 14, col size: 10

Both chip select CSD0 and CSD1 are used 

Density per chip select: 512MB

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

Error: DDR density on board is NOT compatible to your selection!

Modify and Re-download again!!!

But I've use the Mx6SL LPDDR2 Script Aid V0.04 tool to generate the inc file with below config

pastedImage_0.png

Would you please give a guidence what's wrong with this?

Hi,

well, according to your spread sheet entry you use two chip select with 1GByte each. The stress test however

calculated that you use only 512MBytes per chip select ...

if you use 8 banks / 14 row addresses and 10 column addresses you have a density of:  8 * 2^10 * 2^14 = 8 * 1024 * 16384 = 128MWords.

With 32Bit wide memories this results in 512MBytes per device or 1GBytes in total.

So I would say the stress tester is wrong and your entries are correct.

Greetings

Andreas

Hi,sir

     I use this tester to do calibration and I got an error,help me please.

     This is my DDR3 information.

pastedImage_0.png

     Then i get this error message on  DDR Stress Test (2.1.0)

pastedImage_4.png

     And  the same error message on DDR Stress Test (2.0.0)

pastedImage_3.png

     But I can pass on DDR_Stress_Tester_V1.0.3 the oldest version which can't get write leveling calibration.

pastedImage_6.png

     Would you please tell me what's wrong with this?

Hi OliverChen,

Does DDR STRESS Tool V2.1 can support mx6qp CPU ?

"Tool freeze when switching frequency"

Hi,

We have a strange behavior when we run the DDR3 stress test (v2.10) on our iMX6SoloX boards.

We have calibrated the memory bus at 396 MHz and it works very well.

We can run our boards in stress test mode over extensive periods of time (also in a temperature chamber). It works perfect on 380 MHz, 396 MHz, etc.

However, it we set the frequency sweep to 360-440 MHz, it appears that the iMX6SoloX freeze when switching from 380 to 396 MHz. Not immediately, but after 5-10 switches. The behavior is not temperature dependent. The freeze will eventually always happen. We see the same behavior on all boards we have tested.

Note that the system does not freeze during the stress tests but (it appears to be) when changing operating frequency. The printouts from the stress test at 380 MHz show success but we do not see any printouts from the 396 MHz test that is about to start next.

It can possibly be the GUI application that freeze.

It can possibly be the iMX6SoloX that freeze.

It can possibly be USB communication that is lost.

We cannot really determine where the problem is.

It is worth noting that the old stress test application (v1.0.3) does not give this freeze problem. This application takes much longer so we do not have the same amount of data from this run. Up until now we have at least not experienced any freeze on this version of the stress test.

Can it be a problem in the application that runs the stress test on the iMX6SoloX (typically in the process of switching between frequencies)?

Is there any other tests that we can do to track down the problem?

Is the source code available for the stress test application that is downloaded?

Kind Regards,

Anders

Hi lql,

It is a software bug when apply 4GB DDR size in V2.10 version.

The bug is fixed by V2.20.

B.R

Oliver

Hi, Apollo,

mx6qp can use mx6dq CPU option.

But it needs mx6dp's own script file.

B.R

Oliver

Hi Anders,

Thank you very much to give me the detailed feedback.

1. In our old version DDR Stress Test tools (V2.10 and V1.03 or other old version), there is DDR precharge command issue when switch DDR frequency. So you've found problem in frequency sweep from 360Mhz to 440Mhz.

2. You said there was no freeze issue in V1.03 verion. How about frequency sweep problem when you use V1.03?

3. About V2.10 freeze issue, I want to know the exact "freeze" meaning. It means the Software GUI show "Application is Not respond"? Or there is no message output and all the buttons ares disabled? If it is the latter, I think the board is hung, not the GUI application is freeze.

Please try the V2.20 version which is fixed many bugs including DDR precharge command issue.

By the way, I can't response this thread quickly. If you have urgent questions, please send me email: b35383@freescale.com

B.R

Oliver

Is there any reason why a board that passes the V1.0.3 test would fail the V2.20 test? I have boards that have passed several hundred loops and several runs through the V1.0.3 tester fail the DQS Gating Calibration every time on V2.20. Is it more intensive and thus able to find problems better? For reference I tried using the same calibration file in both versions.

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

        DDR Stress Test (2.2.0)

        Build: Sep 21 2015, 23:31:32

        Freescale Semiconductor, Inc.

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

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

        Chip ID

DIGPROG(0x020c8260) = 0x00610001

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

Internal Revision = TO1.1

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

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

        Boot Configuration

SRC_SBMR1(0x020d8004) = 0x40000000

SRC_SBMR2(0x020d801c) = 0x22000001

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

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

        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 Tempareture: 54

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

DDR Freq: 396 MHz

ddr_mr1=0x00000000

Start write leveling calibration...

running Write level HW calibration

Write leveling calibration completed

    MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x004D005C

    MMDC_MPWLDECTRL1 ch0 (0x021b0810) = 0x00420045

    MMDC_MPWLDECTRL0 ch1 (0x021b480c) = 0x00290027

    MMDC_MPWLDECTRL1 ch1 (0x021b4810) = 0x0031004E

Write DQS delay reult:

   Write DQS0 delay: 92/256 CK

   Write DQS1 delay: 77/256 CK

   Write DQS2 delay: 69/256 CK

   Write DQS3 delay: 66/256 CK

   Write DQS4 delay: 39/256 CK

   Write DQS5 delay: 41/256 CK

   Write DQS6 delay: 78/256 CK

   Write DQS7 delay: 49/256 CK

Starting DQS gating calibration

. . . . . . . . . . . . . . ERROR FOUND, we can't get suitable value !!!!

dram test fails for all values.

Error: failed during ddr calibration

pastedImage_1.png

Hi Oliver/Li Chen,

Thank you for your response and for the new version of the tool. I can confirm that we no longer have any issue when running v2.20 of the stress test tool. We have run frequency sweeps all day. There is no freeze when switching between frequencies anymore.

Regarding your questions; "You said there was no freeze issue in V1.03 verion. How about frequency sweep problem when you use V1.03?"

We didn't see any freezes when sweeping frequencies on v1.03. Only on V2.10.

Regarding your question what a "freeze" really means; we run the over-night test and there is no way to stop that test in v2.10 other than closing the PC GUI application. The "freeze" that we reported means that the output in the terminal window stopped (at the point when the frequency should change). Since the PC GUI application is designed as it is in v2.10 it is not possible for us to determine if it is the PC application or CPU that has frozen, but if I understand you correctly we should have received a message "Application not responding" from Windows if the PC GUI application had frozen... so likely it was the CPU that was frozen then.

Anyhow, I think it is clear now that there was a bug in v2.10 of the stress tool. By the way, we are using two 4Gbit DDR3L memories in our system.

Kind Regards,

Anders

Hi Anders,

Stress Test tool V2.10 waits for test OK or test fail information and then enable all buttons. If i.MX cpus hangs and doesn't send back the response, GUI application will wait forever. It isn't program freeze, but some problem in board.

V1.03 is a simple command line and it only shows message get from the board. There is no communication protocol.

For your i.MX6sx DDR stress Test failure, I've sent a debug binary to your email.

B.R

Oliver

Hi craigcomberbach,

In V1.03 version, stress test tool requires you to input MR1 value and use it to do DQS gating calibration.

In V2.xx version, stress test tool will read this value from script (register MMDC0_MDSCR/0x021b001c). Usually it is the last line in your script.

for example,

setmem /320x021b001c =0x00000000// MMDC0_MDSCR

it sets MR1 = 0x0;

setmem /320x021b001c =0x00040000// MMDC0_MDSCR

it sets MR1 = 0x04;

Can you align it and re-test it again?

B.R

Oliver

We are still having errors with 4GB selected with V2.2 for i.mx6Q.

Used the programming aid to generate .inc file.

This .inc file works with 1.0.2.

The settings in the .inc work with uboot/Linux

So, we believe the settings are valid, but V2.2 is still giving an error.

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

DDR Stress Test (2.2.0)

        Build: Sep 21 2015, 23:32:59

Freescale Semiconductor, Inc.

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

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

Chip ID

DIGPROG(0x020c8260) = 0x00630002

CHIP ID = i.MX6 Dual/Quad (0x63)

Internal Revision = TO1.2

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

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

Boot Configuration

SRC_SBMR1(0x020d8004) = 0x04003040

SRC_SBMR2(0x020d801c) = 0x3a000001

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

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

DDR configuration

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

DDR type is DDR3

Data width: 64, bank num: 8

Row size: 16, col size: 10

Chip select CSD0 is used

Density per chip select: 4096MB

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

Error: DDR CS on board is NOT compatible to your selection!

Modify and Re-download again!!!

*****************************U_BOOT_JTAG_VERSION*************************************************

U-Boot > go 0x907000

## Starting application at 0x00907000 ...

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

DDR Stress Test (2.2.0)

Build: Sep 21 2015, 19:26:38

Freescale Semiconductor, Inc.

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

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

Chip ID

DIGPROG(0x020c8260) = 0x00630002

CHIP ID = i.MX6 Dual/Quad (0x63)

Internal Revision = TO1.2

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

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

Boot Configuration

SRC_SBMR1(0x020d8004) = 0x04003040

SRC_SBMR2(0x020d801c) = 0x3a000001

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

What ARM core speed would you like to run?

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

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: 16, col size: 10

Chip select CSD0 is used

Density per chip select: 4096MB

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

Current Tempareture: 55

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

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): 3840

Error: DDR density on board is NOT compatible to your selection!

Modify and Re-download again!!!

Regards,

Brett

Hi,

I have been trying to run the serial port version of the stress test utility on our custom board, however the software keeps reporting a, "NOT SUPPORTED" error.

The board features an i.MX6SL, and implements DDR3 memory. Is it possible to get a version of the software that will work with this configuration?

The output from the utility follows.

U-Boot 2014.04-08637-gaffa032-dirty (Oct 01 2015 - 04:26:21)

CPU:   Freescale i.MX6SL rev1.2 at 792 MHz

CPU:   Temperature 54 C, calibration data: 0x59951a5f

Reset cause: WDOG

Board: MX6SLMIOT1

I2C:   ready

DRAM:  1 GiB

WARNING: Caches not enabled

MMC:   FSL_SDHC: 0

In:    serial

Out:   serial

Err:   serial

mmc0 is current device

Net:   FEC [PRIME]

Hit any key to stop autoboot:  0

=> fatload mmc 0:1 0x907000 ddr-test-uboot-jtag-mx6sl.bin

reading ddr-test-uboot-jtag-mx6sl.bin

48204 bytes read in 21 ms (2.2 MiB/s)

=> go 0x907000

## Starting application at 0x00907000 ...

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

        DDR Stress Test (2.2.0)

        Build: Sep 29 2015, 22:54:05

        Freescale Semiconductor, Inc.

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

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

        Chip ID

DIGPROG(0x020c8280) = 0x00600002

CHIP ID = i.MX6 SoloLite (0x60)

Internal Revision = TO1.2

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

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

        Boot Configuration

SRC_SBMR1(0x020d8004) = 0x00002042

SRC_SBMR2(0x020d801c) = 0x20000011

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

What ARM core speed would you like to run?

Type 1 for 800MHz, 2 for 1GHz

ARM Clock set to 1GHz

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

        DDR configuration

DDR type is DDR3

Data width: 16, bank num: 8

Row size: 15, col size: 10

Both chip select CSD0 and CSD1 are used

Density per chip select: 512MB

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

Current Tempareture: 57

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

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

Please enter the chip select(s) to be tested

Type 1 for CS0 only, 2 for both CS0 and CS1

  You have chosen to test both chip selects

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

Current Tempareture: 61

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

DDR Freq: 396 MHz

t0.1: data is addr test

t0: memcpy11 SSN test

ERROR: NOT SUPPORTED

Error: failed to run stress test!!!

Kind Regards

Dave

Hi Li Chen,

I got the same problem as Craig mentioned on Sep 22. My DRAM script is for i.MX6DL LPDDR2 single channel fixed mapping. It passed several hundred loops in stress test tool v1.0.3 but it can't even pass one loop in v.2.2 at the same DDR frequency.

I don't understand your reply on Sep 23. My last few lines of my DRAM script is as below. Could you please advise why it fails in v2.2?

// Channel 0 CS0

setmem /320x021b001c =0x003F8030// MRW: BA=0 CS=0 MR_ADDR=63 MR_OP=0 (Reset)
setmem /320x021b001c =0xFF0A8030// MRW: BA=0 CS=0 MR_ADDR=10 MR_OP=0xff (IO calibration, calibration code)
setmem /320x021b001c =0x82018030// MRW: BA=0 CS=0 MR_ADDR=1  MR_OP=see Register Configuration
setmem /320x021b001c =0x04028030// MRW: BA=0 CS=0 MR_ADDR=2  MR_OP=see Register Configuration
setmem /320x021b001c =0x01038030// MRW: BA=0 CS=0 MR_ADDR=3  MR_OP=see Register Configuration

// Channel 0 CS1

setmem /320x021b001c =0x003F8038// MRW: BA=0 CS=1 MR_ADDR=63 MR_OP=0 (Reset)
setmem /320x021b001c =0xFF0A8038// MRW: BA=0 CS=1 MR_ADDR=10 MR_OP=0xff (IO calibration, calibration code)
setmem /320x021b001c =0x82018038// MRW: BA=0 CS=1 MR_ADDR=1  MR_OP=see Register Configuration
setmem /320x021b001c =0x04028038// MRW: BA=0 CS=1 MR_ADDR=2  MR_OP=see Register Configuration
setmem /320x021b001c =0x01038038// MRW: BA=0 CS=1 MR_ADDR=3  MR_OP=see Register Configuration

//final DDR setup, before operation start:

setmem /320x021b0020 =0x00007800// MMDC0_MDREF
setmem /320x021b4020 =0x00007800// MMDC1_MDREF, align with Chan 0 setting
setmem /320x021b0818 =0x0// DDR_PHY_P0_MPODTCTRL
setmem /320x021b4818 =0x0// DDR_PHY_P1_MPODTCTRL
setmem /320x021b08b8 =0x00000800// DDR_PHY_P0_MPMUR0, frc_msr
setmem /320x021b48b8 =0x00000800// DDR_PHY_P1_MPMUR0, frc_msr
setmem /320x021b0004 =0x00025564// MMDC0_MDPDC now SDCTL power down enabled
setmem /320x021b4004 =0x00025564// MMDC1_MDPDC now SDCTL power down enabled, align with Chan 0 setting
setmem /320x021b0404 =0x00011006//MMDC0_MAPSR ADOPT power down enabled
setmem /320x021b4404 =0x00011006//MMDC1_MAPSR ADOPT power down enabled, align with Chan 0 setting
setmem /320x021b001c =0x00000000// MMDC0_MDSCR, clear this register (especially the configuration bit as initialization is complete)
setmem /320x021b401c =0x00000000// MMDC1_MDSCR, clear this register (especially the configuration bit as initialization is complete)

Thanks in advance,

mmj

Hi MMJ,

Please read the answer to Craig Comberbach,

If you have enter MR value other than 0000 in V1.03, please write that value to MMDC0_MDSCR in script.

For example, if you input MR=0004, modify the last two lines in your script as follows:

setmem /320x021b001c =0x00040000// MMDC0_MDSCR, clear this register (especially the configuration bit as initialization is complete)

setmem /320x021b401c =0x00040000// MMDC1_MDSCR, clear this register (especially the configuration bit as initialization is complete)

B.R

Oliver

Hi Dave,

16-bit version is not standard release for mx6sl.

Please send me email: b35383@freescale.com and I'll send you a debug version.

B.R

Oliver

Hi Oliver,

I am sorry but I do not understand what is "MR value". Do you mean Mode register? Could you please explain more about this?

As you can see, mode registers 1, 2, 3, 10, 63 had been modify in my script. In this case, how should I modify it for v2.2?

Regards,

MMJ

Hi Oliver,

Any further advice about my LPDDR2 issue in stress test v2.2?

Thanks,

MMJ

Hi MMJ,

Please send me email oliver.chen@freescale.com

B.R

Oliver

LPs

Hi,

  is the ddr-stress-test.bin source code available? I'm looking for the MX6SX project.

Regards

I would like to try U-Boot version of DDR Stress Test Tool v2.20.

My custom board uses UART4 so I was happy to see that it is not necessary to use UART1 anymore.

I flashed the relevant image but it did not start for me. Is it possible that auto-detect UART feature is not working?

Cpu: MX6Q

Signal/Pin: UART4_TX -> KEY_COL0 and UART4_RX -> KEY_ROW0

CONFIG_SPLASH_SCREEN is disabled.

My log:

     U-Boot 2015.04-14312-gf777586-dirty

     CPU:   Freescale i.MX6Q rev1.2 at 792 MHz

     CPU:   Temperature 37 C

     Reset cause: POR

     Board: MX6

     I2C:   ready

     DRAM:  1 GiB

     PMIC:  PFUZE100 ID=0x10

     MMC:   FSL_SDHC: 0, FSL_SDHC: 1

     Using default environment

     In:    serial

     Out:   serial

     Err:   serial

     Net:   FEC [PRIME]

     Normal Boot

     Hit any key to stop autoboot:  0

     => load mmc 0:1 0x00907000 /root/ddr-test-uboot-jtag-mx6dq.bin

     91008 bytes read in 130 ms (683.6 KiB/s)

     => go 0x00907000

     ## Starting application at 0x00907000 ...

And then it freezes...

Any suggestions?

Regards,

  Laszlo

Hi,

I have the same MR1 issue...

I would expect that the MR1 value should be set via setmem /32 0x021b001c = 0x00048031. But also if I put the line setmem /32 0x021b001c = 0x00040000 // MMDC0_MDSCR at the end of my script, the Stress Test Tool keeps saying "ddr_mr1=0x00000000".

I have written down this issue also in a separate thread: Re: DDR Stress Test v1.0.3 vs. v2.20 where I attached my InitScript.

Best regards

Martin

Hi,

I am running a DDR stress test on i.MX6 Solo Lite EVK using the DDR stress test tool v2.20 taken from https://community.freescale.com/docs/DOC-105652

and i am using the LPDD2 script MX6SL_EVK_LPDDR2_512MB_32bit_v0.9.inc available in the tool but when i run the test i get the below error

Logs:

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

        DDR Stress Test (2.2.0)

        Build: Sep 29 2015, 22:40:36

        Freescale Semiconductor, Inc.

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

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

        Chip ID

DIGPROG(0x020c8280) = 0x00600002

CHIP ID = i.MX6 SoloLite (0x60)

Internal Revision = TO1.2

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

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

        Boot Configuration

SRC_SBMR1(0x020d8004) = 0x00002c40

SRC_SBMR2(0x020d801c) = 0x02000001

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

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

        DDR configuration

DDR type is LPDDR2 in 1-channel mode.

Data width: 32, bank num: 8

Row size: 14, col size: 10

Both chip select CSD0 and CSD1 are used 

Density per chip select: 512MB

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

DDR Stress Test Iteration 1

Current Tempareture: 45

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

DDR Freq: 0 MHz

t0.1: data is addr test

t0: memcpy11 SSN test

Address of bank2 failure: 0x8d0029cc

Data was: 0xfdfffff7

But pattern was:          0xfdffffff

Error: failed to run stress test!!!

I have set the configuration in the tool as below:

TARGET : MX6SL

ARM SPEED : Default

Verify DCD Address : Enabled

DDR Density : 512 MB / Default

DDR CS : ALL

DDR Channel : 0

DDR Frequency : 400 MHz

DDR start frequency : 135

End Frequency : 672 / 400

Please let us know what could be the issue

Note : I am able to run the DDR stress test using the tool : DDR_Stress_Tester_V1.0.3. But, when i use the new tool with version 2 which has GUI, I see this problem.

Thanks and Regards,

-Devaraj

Hi OliverChen

Please help us in resolving the error in the previous post.

Thanks and Regards,

-Devaraj

Hi Devaraj,

Please send me email(oliver.chen@freescale.com) and I'll send you a test version to try it.

B.R

Oliver

Hi Oliver,

It seems it is not the only confiuguration not supported:

Same issue on 6SoloX

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

DDR Stress Test (2.2.0)        

Build: Sep 29 2015, 22:38:32       

Freescale Semiconductor, Inc.

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

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

Chip ID DIGPROG(0x020c8260) = 0x00620002

CHIP ID = i.MX6 SoloX (0x62)

Internal Revision = TO1.2

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

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

Boot Configuration

SRC_SBMR1(0x020d8004) = 0x0000d862

SRC_SBMR2(0x020d801c) = 0x3a000001

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

ARM Clock set to 800MHz

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

DDR configuration DDR type is DDR3

Data width: 16, bank num: 8 Row size: 14, col size: 10

Chip select CSD0 is used

Density per chip select: 256MB

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

Current Tempareture: 51

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

DDR Freq: 396 MHz 

ddr_mr1=0x00000000

Start write leveling calibration... running Write level HW calibration Write leveling calibration completed   

MMDC_MPWLDECTRL0 ch0 (0x021b080c) = 0x000A000D   

MMDC_MPWLDECTRL1 ch0 (0x021b0810) = 0x001F001F

Write DQS delay reult:    Write DQS0 delay: 13/256 CK  

Write DQS1 delay: 10/256 CK

Starting DQS gating calibration

ERROR: NOT SUPPORTED

ERROR: NOT SUPPORTED

...

Hello together,

My board uses imx6 dual only has JTAG and UART. So how can I get the information when calibrating the DDR3 RAM?

Could you please let me know all?

I am looking forward to your respond.

Thanks,

Tan

Hi,

I used an iMx6DL with DDR3 and I try the read/write function in the v2.30 and the write function failed.

I have this message when I try to write a pattern :

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

        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

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

addr=0x0000058C,data=0x00000255

Fail to write address 0x0000058c

Could you help me on this ?

Thanks,

Julien

Hi Julien,

I believe that this is due to the fact that the tool can only read from/write to valid DDR address locations, like addr=80000000.  I think addr=0000058C might be the ROM.

Regards,

Mike

I think that this tool now supports downloading the stress test via JTAG.  Looks like there is a zip file called "ddr_stress_tester_jtag_v2.30.zip".  I extracted that contents and found an elf file called "ddr-test-uboot-jtag-mx6dl.elf".  Though it has "u-boot" in the name, I believe it can be used as a JTAGA downloadable elf.  It also seems important to read the text file "add_uart_support_in_script.txt" - it seems to contain important information to configuring the JTAG DDR initialziation script to allow you to choose the desired UART port.

Regards,

Mike

Hi,

We are having smoe issues with these tools. We used the DDR3 scripting aid to construct a correct DDR3 setup. This setup was integrated into our bootloader.

We then used the windows tool to calibrate the memory. The resulting timings where integrated into the bootloader as well. Unfortunately these timings are not stable. It seems they work fine if the bootloader is downloaded through USB serial download. When booting from NAND the board doesn't even boot. On a different board we saw timings that would fail after short time.

The uboot tool seems to work better. DDR3 seems to be stable with these new values.

Any idea why there is such a difference or what may cause the issues with the windows tool?

Here are the calibration results with the windows tool on board A (works for USB serial download but not for nand):

0x021b080c 0x001f0027

0x021b0810 0x0011001b

0x021b083c 0x026C0264

0x021b0840 0x024C0254

0x021b0848 0x3A444844

0x021b0850 0x382E282E

Same board changed calibration so that it boots from NAND:

0x021b080c 0x001f0027

0x021b0810 0x0011001b

0x021b083c 0x021C0264

0x021b0840 0x024C0254

0x021b0848 0x3A444844

0x021b0850 0x382E282E

The uboot tool measures different settings that work:

0x021b080c 0x0015001C

0x021b0810 0x000C0013

0x021b083c 0x021C0218

0x021b0840 0x0208020C

0x021b0848 0x3C404642

0x021b0850 0x3A322E34

Board type B:

not working/windows tool:

0x021b080c 0x00340041

0x021b0810 0x0024002A

0x021b083c 0x0308027C

0x021b0840 0x02580260

0x021b0848 0x444E4C4E

0x021b0850 0x3C342C28

working with uboot tool:

0x021b080c 0x0024002E

0x021b0810 0x001A001C

0x021b083c 0x0230022C

0x021b0840 0x0214021C

0x021b0848 0x424A4A4C

0x021b0850 0x3C38302E

Also I noticed that the uboot tool does not work for setups on i.MX6S and UART5 as debug uart.

Regards,

Markus

Hi Markus,

What does the uboot tool mean? You mean 'ddr_stress_tester_uboot' or some other uboot command?

B.R

Oliver

Hi Oliver,

Yes by 'uboot tool' I meant 'ddr_stress_tester_uboot'.

Regards,

Markus

Hi

I got a question,according to what we set MR1 value = 0x0004 when  do DDR3 calibration?

Can you tell me,please.

Best Regard

Qiulong Li

Hi,

have a look into the datasheet of your memory chip. There you can find an explanation of the Mode Registers (MR0..MR3).

Best regards

Martin

Hello,

We have a custom board based on i.MX6DL processor with 2xDDR3 memory chips. We genarate dram script with "i.Mx6DQSDL DDR3 Script Aid V0.10" and we use the v2.4 version of FSL test tool.

The problem is that DQS calibration fails all the time, also, the stress test. However, random access work most of the time but occasionally fail.

Have you any proposal? Thanks.

Regards,

Thabet

Hi,

I run ddr calibration using DDR Stress Test Tool V2.51 and obtain the calibration results,whether these calibration parameters are written to the kernel uboot / .. mx6q_sabresd / flash_header.S  automatically or manually?

Best regards

Sunny

Hi Sunny,

You will have to manually update the flash_header.S or any other DDR init script with these updated calibration values.

Regards,

Mike

Hi Mike,

Thank you for your reply.Do you have a DDR init script or do you kown where i can get,because modifying these values is a huge task for many boards.

Regards,

Sunny

Hi Sunny,

You can find some example scripts in ddr_stress_tester_v2.51\script folder (in ddr_stress_tester_v2.51.zip).

Regards,

Mike

Hello,

My custom i.mx6Q based board passes ddr stress test v2.40 at 400MHz. The test has been run for 15 hours without a problem.I want to report an issue about memory read/write function of the tool. The tool sometimes freezes when a single memory read or write is done. I am sure that the addresses i am trying to read or write falls in a valid region in a memory map. Furthermore, i can read from/write to ram memory with an emulator without a problem. Here is a topic i have started regarding this issue. What could be the possible reason for this?

i.MX6Q DDR TESTER TOOL MEM32bit WRITE/READ

Hello,

looks like, the version 2.51 has problems with i.MX6SX.

imx6 SoloX; USB error attempting to run DDR Test Tool V2.51


It is reprodusable on my board too.

The previous release V. 2.50 is working.

Regards,

Yuri.

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