We have our custom design based on i.MX535 with Elpida EDB4032B2PB (512MB LPDDR2-S4) & Samsung KLM4G1FE3B-B001 (4GB eMMC Flash). The product is in the hardware bringup phase. To check the processor memory interface, the DDR Stress Test was performed and the result of the same is herewith attached.
1. Since there is no detailed user manual or guide for this stress test regarding the observation or results, Pls advice what does this result as per the attachment signify? Is there any way to identify where the problem exists?
2. Does DDR Stress Test carry out rigorous testcases with varying test patterns to validate the interface? Is there any document to understand or infer from the results? What is the procedure being adopted during the test?
3. Do we have any bare metal tests for i.MX535 Sabre/QSB interfaces to test via the JTAG Emulator?
Pls advice.
Solved! Go to Solution.
Please verify if the PCB design meets design checklist recommendations.
Also, DDR calibration may be performed.
Thanks Yuri for the clarification.
Sorry for not updating my results.
Well meanwhile tried bringing up another hardware. As per advice DDR stress test passes till 350MHz in this hardware. So DDR till 700MHz is fine. Happy that the basic hardware is fine & we have got the right configuration details as well. Thanks for the support.
But after 350MHz getting errors. Need to analyse this for better performance.
Thanks Yuri.
Please verify if the PCB design meets design checklist recommendations.
Also, DDR calibration may be performed.
Yes will do the same.
Do we have any references for LPDDR2 relevant pcb design checklist & for DDR calibration?
Thanks Yuri for the support.
The DDR relevant read & write delay lines were tuned to get the stress test working till 400MHz in our hardware platform.
Thanks.
Looks like memory is not good (write 0xFFFFFFFF, read 0x1). Is Your init script (init3.inc) correct for LPDDR2 ?
It was editted as per datasheet. But may be something is wrong. Can you share a validated init script for i.MX535-LPDDR2?
Thanks.
Thanks Yuri. Electrical specifications are the same between the part that we have used & the one adviced in the init file.
1. Tried the test with this init file. Pls find the screenshot. Any feedback on this? Is it that the data written is 0xffedffff, but the read value is 0xffffffff?
2. Is it that the first address being written itself is 0x70800000?
3. Is there any way to change the test pattern to diagnose the problem?
4. Also would like to know the way the stress test is performed in terms of the patterns, sequence of test patterns used & the result that is expected, etc. In case of failure how to infer the result data? Do we have any document which can specify the same?
Sorry for delay.
Looks like the memory is not working correctly.
As for the stress tests - usually sources are not provided (because of some internal reasons).
Nevertheless, hope the following may be helpful.
Below is a list of each sub test along with their respective definitions. Note the acronym
SSN stands for simultaneous switching noise.
t0: memcpy11 SSN test (DDRtest_memcpy11_SSN.c )
This test is similar to the memcpy11 random pattern test (described below) which
makes use of the custom written memcpy11 function. However, this test uses data
patterns to help root out SSN and does not increment the starting address. This test
also breaks up the total DDR density into four “banks”, where each bank contains a
different SSN data pattern.
t1: memcpy8 SSN test (DDRtest_SSN_memcpy_test.c)
This test performs “memcpy” bursts of various stress patterns (walking ones and
walking zeros, A’s followed by 5’s, etc) using copy_words_using_eight_registers to
help determine or weed out simultaneous switching signal noise.
t2: memcpy11 random pattern test (DDRtest_memcpy11_pseudo_random_with_offset.c)
This test utilizes a custom written memory copy function that issues 11-word load
and store multiple instructions, to test the bursting behavior of the DDR
interface. Each time through the memcpy11 test, the start address is incremented in
steps of four bytes to test different burst access types, especially important when
caches are enabled to initiate burst wraps for cache line fills. The data pattern used is
pseudo-random. This test also breaks up the total DDR density into four “banks”,
where each bank contains a different “seed” for each pseudo-random data
pattern.
t3: byte-wise SSN test (DDRtest_byte_SSN_test.c)
The purpose of this test is to root out any SSN within byte lanes. It accomplishes this
by writing byte-wise patterns to one location and the inverse of each byte to the
subsequent location. Each of the four bytes values are equal to one another and the
test increments the byte pattern as follows (with the inverse value in brackets:
0x00000000 [0xFFFFFFFF]; 0x01010101 [0xFEFEFEFE]; 0x02020202
[0xFDFDFDFD]; … 0xFFFFFFFF [0x00000000].
t4: IRAM_to_DDRv2 test (DDRtest_IRAM_to_DDRv2.c)
This test is similar to the IRAM_to_DDRv1 test, but instead transfers the data 1000
times per test to ensure that the data never changes to root out random glitches. Also,
the test uses different data patterns than the IRAM_to_DDRv1 test to further root out
SSN.
t5: IRAM_to_DDRv1 test (DDRtest_IRAM_to_DDR.c)
The purpose of this test is to root out any SSN and isolates the DDR read and write
accesses by using the IRAM as an intermediate data storage location. This test
moves a user defined length of data using the copy_words_using_eight_registers
function from DDR to IRAM and then from IRAM to a different DDR location, then
compares DDR location 1 and location 2. The data pattern used is pseudo-random.
t6: read noise walking ones and zeros test (DDRtest_read_noise_walking_test.c)
This test helps to identify if there any signal integrity issues or cross talk between
data lines or other control signals by doing four sets of test on both CSD0 and CSD1
(if CSD1 is populated).
Read from DDR walking ones – this test writes a set of 0xFFFFFFFF
followed by a walking ones pattern to memory and then reads it back in a
two word burst (if there are issues, the read will not return a one)
Read from DDR walking zeros test – this test writes a set of 0x00000000
followed by a walking zeros pattern to memory and then reads it back in
a two word burst (if there are issues, the read will not return zero)
Write to DDR walking ones test – this test will use an STM to write a two
word burst to memory a set of 0xFFFFFFFF followed by a walking ones
pattern and then reads it back non-burst (if there are issues, the read will
not return a one)
Write to DDR walking zeros test – this test will use an STM to write a
two word burst to memory a set of 0x00000000 followed by a walking
zeros pattern to memory and then reads it back non-burst (if there are
issues, the read will not return zero)