LPDDR4 8GB on i.MX8QM

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

LPDDR4 8GB on i.MX8QM

3,148 Views
rogerio_pimentel
Contributor III

Hi,

I have a board using i.MX8QM based on i.MX8QM MEK board. I have used 2 x MT53D512M32D2 (Total 4GB DDR memory) and it works without problems.

Now I want to double the memory to 8GB. I see that the MT53D1024M32D4 LPDDR4 was already being validated by NXP/Micron but as this part is not available, I'm trying to use MT53E1G32D2 that is supposedly 100% compatible.

I can't make it work with more than 4GB.

I made the following steps:

1 - Filled the RPA spreadsheet v23 according to the new memory and my board's schematics (both in annex)

2 - Copied the "DCD CFG file CBT" tab content to imx-scfw/mx8qm_b0/platform/board/mx8qm_newboard/dcd/imx8qm_dcd_1.6GHz.cfg

3 - Built the scfw firmware for stress test application using:

make -C /chimera/imx-scfw/mx8qm_b0 qm B=newboard DDR_CON=ddr_stress_test_parser V=1 R=B0

 

4 - Copied the built scfw_tcm.bin file to mx8_ddr_stress_test_ER15/bin/mx8qmb0_scfw_download.bin

5 - Opened DDR stress test tool and set it for i.MX8QM and density = 8GB

6 - The stress test returns some errors (please see attached stress_test_log.txt)

7 - If I change "Number of Chip Selects used" from 2 to 1 on RPS spreadsheet. The stress test passes but with 4GB only.

 

My questions:

1 - Am I doing something wrong on my steps?

2 - Is it possible to review my RPA spreadsheet? (Stress test app log, RPA spreadsheet and schematics attached)

3 - Have MT53E1G32D2 been validated by NXP on i.MX8QM?

4 - Is there any other 1Gb LPDDR4 partnumber recommendation that was validated?

Thank you,
Rogerio

0 Kudos
Reply
9 Replies

3,122 Views
hector_delgado
NXP TechSupport
NXP TechSupport

Hi @rogerio_pimentel ,

I hope you're doing well. Let me review this and I'll get back to you as soon as possible.

Best regards,
Hector.

3,081 Views
rogerio_pimentel
Contributor III

Hi @hector_delgado ,

Thanks for answering my question.

Did you have a chance to take a look on it?

Best regards,

Rogerio

0 Kudos
Reply

3,022 Views
rogerio_pimentel
Contributor III

Hi @hector_delgado ,

Do you have some update on this issue?

Thanks,

Rogerio

0 Kudos
Reply

3,015 Views
hector_delgado
NXP TechSupport
NXP TechSupport

Hi @rogerio_pimentel ,

I hope you're doing well. MT53E1G32D2 is validated to work with the i.MX8QM with a maximum supported density of 32GB/4GB (per controller) with dual rank, dual-channel  device with 16-row addresses (R0-R15) as the assumed memory organization. 

Other validated parts working with i.MX8MQ: MT53B768M32D4NQ, MT53D1024M32D4DT, MT53D512M32D2DS, NT6AN512T32AC, and NT6AN512T32AC.

Since your stress test logs returned a training error please try these and let me know if it solves the issue when running the stress test again:

  • Check all voltages:
    o LPDDR4: VDDQ/VDD2=1.10V, VDD1=1.8V; MX8: MEMC=1.10V

    o DDR3L: VDD/VDDQ=1.35V, VREF=0.675V; ; MX8: MEMC=1.10V

  • Check RPA configuration to ensure it matches the DDR data sheet like number of chip selects, number of rows, data bus size
    o Double check the board data bus mapping and ensure it matches the schematic

    o If the board data bus mapping is not accurate, it can result in data training failures

  • Try adjusting DDR_PHY_ZQ1PR0 bit ZPROG_HOST_ODT from 48ohm to 60ohm (i.e. increase ODT value from current, default setting) to see if this has some impact on data training issue
    o This can be performed in the RPA tool: in the Register Configuration tab, locate the
    DDR_PHY_ZQ1PR0 register and use the pull-down menu to adjust ZPROG_HOST_ODT

    o If this resolves the issue, it could indicate a layout or board assembly (solder) issue

  • If data training failure persist after verifying voltages are stable/nominal and verifying other items above, this could be a PCB, board, or other hardware related issue.

 

Best regards,
Hector.

0 Kudos
Reply

3,011 Views
rogerio_pimentel
Contributor III

Hi @hector_delgado ,

Thank you very much for the information and all your suggestions.

I'll check all points.

Best regards,

Rogerio

0 Kudos
Reply

2,981 Views
rogerio_pimentel
Contributor III

Hi @hector_delgado,

I checked all the points and made all the tests you suggested and I continue having the same problem.

Is it possible for you to share the RPA spreadsheet used to validate MT53E1G32D2 ? 

Thanks,

Rogerio

0 Kudos
Reply

2,929 Views
hector_delgado
NXP TechSupport
NXP TechSupport

Hi @rogerio_pimentel ,

Let me check with our team if we have that available to share. In the meantime, this issue can be explored further cause it can be PCB, board, and other hardware related:

Check the LPDDR4 PCB landing pad size requirements against the LPDDR4 solder ball size:

o If using different LPDDR4 memory devices, their solder ball sizes may be different

o Newer LPDDR4 may have an increase in solder ball size to improve Solder Joint Reliability

o For example, say the solder ball size changed from 312u to 363u:

For the 312u pad size, say the user previously used a 250u pad size

To effectively use the 363u ball size, the pad size should be around 280u-300u and a NSMD opening of around 350u

If you're using a 250u pad with a 363u ball, then it is very possible that there might not be enough surface area to make good contact

Contact with the DRAM vendor for guidance

Try to ascertain if the issue is board or manufacturing related:

o Has the board been re-worked changing with the DDR memory or i.MX8 SoC? Re-works are strong points for further investigation.

o Re-flow the board to determine if there are any cold solder joints, etc

o Perform an ABA swap of the i.MX SoC and/or memory to see if the issue follows the SoC or memory device (if it follows the SoC, then engage field quality)

o Perform X-rays of the i.MX SoC and DDR and of suspected PCB traces

Thoroughly inspect each component (resistors, capacitors) to ensure that the correct component and it’s correct/intended value is assembled

Reduce the DDR frequency to see if it has any effect; this could point to a board routing issue (cross talk, simultaneous switching noise)

Run board level simulations to ensure board is properly routed and always follow the guidelines presented in NXP’s Hardware Developers Guide

Try adjusting the VDDRIO voltage (try increasing from 1.10V to 1.15V) to see if it makes a difference; may indicate an issue with PMIC or IR drop due to layout

Try adjusting the MEMC voltage (nominal 1.10V); may indicate an issue with PMIC or IR drop due to layout.
 
Best regards,
Hector.
0 Kudos
Reply

2,899 Views
rogerio_pimentel
Contributor III
Thank you very much @hector_delgado,
I'll reviewing all the suggested points with the Hardware Engineer.

In the meantime, if you could find and send me the RPS spreadsheet for MT53E1G32D2 would be awesome.

Thank you!
Rogerio
0 Kudos
Reply

2,615 Views
rogerio_pimentel
Contributor III

Hi @hector_delgado ,

Finally solved the problem.

I was using a wrong Micron silicon revision. I hadn't noticed that the silicon revision would change a lot the internal DDR architecture. The one we were using had only one CS and one more row, not compatible with i.MX8QM.

I was trying MT53E1G32D2FW-046 WT:A while I had to use MT53E1G32D2FW-046 WT:B

I got a MT53E1G32D2FW-046 WT:B​ sample and my board recognized and passed the stress test using 8GB (2 x 4GB).

Thank you very much for all your help and advices.

Best regards,

Rogerio