i.MX7 with 400MHz DDR3L hangs when exiting self-refresh

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

i.MX7 with 400MHz DDR3L hangs when exiting self-refresh

1,267 Views
billgessaman
Contributor IV

Hardware / Software Summary:

  • Custom i.MX7D board based on MCIMX7SABRE board
  • Silicon rev 1.2 (MCIMX7D5EVM10SC)
  • BSP L4.1.15-1.0.0-GA
  • 1 GByte (x32) of DDR3L
    • 2x Micron MT41K256M16TW-107 IT:P
    • 2x ISSI IS43TR16256AL-125KBLI
    • 2x Kingston D2516EC4BXGGBI-U 
  • PMIC PF3000A1EP

Our custom board design is closely based on the i.MX7 Sabre board with the addition of a FPF1504L power switch to gate the i.MX7 NVCC_DRAM rail when the system goes into LPSR mode.  The power switch is controlled by the i.MX7 SNVS_TAMPER9 pin as described in section 5.1.4.5.7 DRAM IO Power of the reference manual.

I have used the latest version of the i.MX7D DRAM Register Programming Aid to determine register settings for both 400 MHz and 533 MHz DDR3L operation.  I have applied these register settings to u-boot to do the DDRC/DDRP configuration using DCD data as well as the other option which uses the plugin mode for initialization.  Systems successfully boot and run at either clock frequency, but operation at 533 MHz for the memory will successfully resume after the memory is put into self-refresh.

A system configured to operate at 400 MHz will hang in various ways during the resume and I see the same behavior if a powered suspend is done (i.e. PMIC stays on with i.MX7 PMIC_STBY_REQ high) or if LPSR mode is used where the PMIC is turned off and only SW3, VLDO1 and VLDO3 are left on.

My Questions:

  1. I don't see anything in the DRAM Register Programming Aid that specifies the register values for changing the CCM_ANALOG_PLL_DDR register to something other than the default of 0x0060302c for 533 MHz operation.  Shouldn't this be accounted for in the DStream tab of the spreadsheet so that the clock is configured properly for 400 MHz operation?
  2. Is there any clock frequency dependent DDR3 self-refresh entry / exit timing that isn't accounted for in the programming aid or by the Linux suspend / resume software?  I know that this is a broad question but I can't pin down why the memory is getting corrupted when self-refresh is entered / exited at a slower clock rate, but at the more common higher clock rate of 533 MHz it works very well.

Has anyone had a similar experience?  I'm clearly going to use 533 MHz until further notice, but issues like this should be understood to make sure that they are not indicators of other issues.

Thanks,

Bill Gessaman

Labels (2)
4 Replies

781 Views
Yuri
NXP Employee
NXP Employee

Hello,

 

  Have You tried the DDR Stress memory test with Your memory configuration ?

 

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

 

 It may be recommended to use memory (timing) configuration for maximal

frequency (533MHz) for all frequency diapazon.

 

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

781 Views
billgessaman
Contributor IV

Hi Yuri,

I did put the DDR Stress Test Tool to work over the last week or so and used the calibration on a group of 11 of our boards to come up with new values for the DDR_PHY_OFFSET_RD_CON0 and DDR_PHY_OFFSET_WR_CON0 registers. I did this for both 399 MHz and 528 MHz DDR operation.  Utilizing these new read / write delay values, I ran overnight memory stress tests without any errors at either DDR operating frequency.  With this I have even more confidence that the DDR layout and timing are solid.

I then modified our memory controller initialization code in u-boot to include the new calibration values.  Once again I'm seeing that doing a suspend / resume that puts the DDR in and out of self-refresh will work reliably at 533 MHz but will cause the system to hang when configured for 400 MHz.  At 400 MHz, it does sometimes work but after less than 10 iterations through suspend / resume it will hang and not be responsive to the console serial interface or the USB device interface.

Your recommendation was to use the memory configuration for maximal frequency (533 MHz) for all frequency ranges?  If I use 533 MHz configuration, but operate at 400 MHz then wouldn't the timing between refresh cycles be longer than it should be since it is based on a number of clock cycles?  This would make the timing for tREFI about 33% more than what is specified for the memory.

I will continue to use 533 MHz for the DDR configuration, but I will remain somewhat uncomfortable not knowing why 400 MHz DDR operation doesn't work reliably for suspend / resume.

Thanks,

Bill

0 Kudos

781 Views
Yuri
NXP Employee
NXP Employee

Hello,

  if some  timing parameters have min and max values, say for range of operating

frequencies - it may be recommended to choose the minimum timings.

 

Regards,

Yuri.

0 Kudos

781 Views
billgessaman
Contributor IV

Hi Yuri,

Thanks for pointing out that the DDR Stress Test Tool has been updated to include the i.MX7.  When I asked about DDR calibration and stress test for the i.MX7 via the private support channel to Freescale (May 2016), the response was "There is no calibration function in i.MX7 and no schedule to implement.".  Evidently this has changed in the last year!

I will download the tool and see what it yields on our design.

Thanks,

Bill