T1042 DDR4 Initialization Failure

[dbevans42]

I have a T1042 design using 64-bit interface to DDR4.  We already found an issue with an improper bit swap between nibbles in the uppermost byte of the interface which we know cannot be compensated for in SW settings.  We are going to implement a fix in a PWB revision.  However since the rest of the bits are correct and the swapping falls into what is allowed according to the reference manual we are hoping to instead operate in 32-bit mode so that we can still proceed bringing up SW and the rest of the design.  I have tried this using QCVS DDR validation tool, however I cannot get the memory to initialize.  I have input the parameters of the device and made sure to set the DQ mapping values according to my design for DQ[0:31] however I continue to get bit ACE= 1 in the ERR_DETECT register.  The processor is getting the RCW via SPI interface and the DDR frequency is set to 800MHz.  Is there a way to use CodeWarrior/QCVS to verify it received the correct RCW value?  What are some other settings to consider for 32-bit mode operation that could explain why it is not working?  I would greatly appreciate any support.  Thank you.

[June_Lu]

I am glad we could identify the root cause.

It may also be beneficial to adjust the DQ mapping in the current design, if possible, before the next board revision.

It would be great if you could share your results when they become available.

If you have any questions, please feel free to let me know.

I will be OoO more than 1 week, so my response may be delayed. I will get back to you if there is any update.

Thanks.

[June_Lu]

Hi @dbevans42 

This is a debug-only workaround that allows a DDR4 board with incorrect bit swapping to operate at a reduced data rate, helping to confirm that no other board-level issues exist. However, the board design must eventually be corrected according to AN5097.

The maximum supported data rate in this mode is 1200 MT/s.

Here the explanation from internal team:

DEBUG_2[27:FRC_SE] means that slow enable is forced low, this can be used to allow DDR4 to train the CAS to preamble and RX bit deskew by slowing the interface down during writes to memory. Normally, DDR4 will train by issuing MRS commands to the multi-purpose register(s) instead of writes. If FRC_SE bit is set, then MPRR and MPRW commands are not supported. In addition, this also means that VRef training is not supported (for Internal or DRAM VRef training) if FRC_SE is set.

 QCVS validation does not support this workaround; it is useful for DDR init software debug only, and the required settings must be incorporated in DDR init before memory enable.

I have reviewed the schematic screenshots you provided and noticed that the T1042 pin numbers shown in your MPU library do not match those in the datasheet.

Could you please verify that the correct MPU library is being used? In addition, please provide the complete schematic symbols (library definitions) for both the T1042 and the DDR4 device. You may also want to double-check why the T1042 pin numbers in your schematic differ from those specified in the datasheet.

Thanks

[dbevans42]

Hello June,

I think you've identified the root cause of our issue.  We have several designs dating back several years which use the incorrect MPU symbol with DDR3L running at 1000MT/s and they have never had any issues.  It never occurred to us that there could be an error in the symbol for that reason.  We are working to review our mapping, correct the symbol, and identify how/why this issue has persisted for so long.  We should be able to correct this issue in upcoming new board spin.  Thank you greatly for the continued support.  We should be able to move forward at this point.

Regards,

Doug

[June_Lu]

@dbevans42 

A-009942 at 650 MHz should be applied in the script, you could add one more line  same as 667 to include this.

Please kindly share the DDR device part schematics to confirm the DQ mapping.

If the DQ mapping cross the MAP, we have one debug mode, it is a temporary solution till you fix your board.

1. set the data rate to 1200MT/s
2. set DDR_SDRAM_CFG_2[DDR_SLOW] = 1
3. set DDR register at offset 0x8F04[27] = 1, or write a value of 0x10 to offset 0x8F04.
4. clear all DDR_DQ_MAPn registers

Thanks

[dbevans42]

Hello June,

I was able to implement the workaround you listed within our GreenHills probe startup script and from what we can tell the DDR4 interface is now working.  We can load code into DDR4 and start executing and I am able to see the initialized data value in DDR4 using the GH probe memory view.  Script attached for review.

Questions:

1) Can you provide more detail on the debug mode?

2) Does the debug mode workaround only function at 1200MT/s or can it be run faster?

3) Is there a bug in the function of the DQ map registers?  I need to be sure that the DQ map registers actually work as advertised and that if I fix the mistaken DQ57 and DQ63 swap in a new spin that it will still work without the debug mode.

4) Is there a bug/issue with 32-bit mode?  It does not make sense that 32-bit mode without debug workaround does not work since we follow the mapping rules for those bits.

5) Is there a way to run workaround debug mode and use QCVS DDRv tool to get correct write leveling values?

[dbevans42]

My last post to you on Thursday 9/24 I attached the relevant schematic screenshots for DQ[0:31] and ECC.  I'm including the snapshots again of the whole 64-bit interface with the erroneous bit swap highlighted.

Thank you for the additional workaround.      

Questions:

1) If I add 650MHz to the A009942 script what value should be written?  Should it be the same as 667MHz?

2) Is the new 1200MT/s workaround you listed meant to make 64-bit mode work even with the erroneous swap, or do we need to continue trying 32-bit mode?

3) Is there a way to do the workaround using the DDRv tool?  Otherwise I will try it within our GreenHills probe startup script and report back with results.

[June_Lu]

Sorry miss the attachment.

[dbevans42]

Hello June,

Thanks for providing the files and the continued support.  I followed your guidelines for QCVS DDRv tool set up and I tried out the errata #A009942 workaround today and it did not seem to make a difference.  I looked into the script itself and it only seems to be applying the workaround for specific frequencies of 667MHz and 800MHz.  I am currently running at 650MHz due to errata #007864 which claims there might be issues with the DDR interface when running at 800MHz for width 32-bit or less.  Is there a debug register value that needs to be set for 650MHz? 

This design is using a single 100MHz clock source so my only options for DDR frequency appear to be 650MHz, 700MHz, 750MHz, and 800MHz for DDR4.  Should I be using a different frequency other than 650MHz for 32-bit mode?

I am still suspicious of the DQ map values.  You actually helped me verify the values a few months ago in another post:  T1042 DDR4 DQ MAP Register Settings

This is a noted difference between this design and the other instance of working T1042 DDR4 on our site.  They used 64-bit and only had minor bit swapping on the most significant byte.  We have a known bad bit swap on the MSB of our 64-bit interface which is why we are attempting 32-bit mode as workaround.  We have a lot more swapping than the working design including a full nibble swap within a byte lane, however the 32-bit LSBs of the interface appear to follow the rules for what is allowed by the T1042 controller.  Are different combinations of the DQ map swapping known to be working?  Can you take another look  at the values we are using to verify?  Register value and schematic captures included for convenience.  The other end at the DDR4 device is a direct 1:1 mapping, so the swapping appears only at the T1042 side for clarity.

Thanks again for the continued support.

[June_Lu]

"ccs::reset_to_debug" work correctly.

Please confirm if errata_A009942 is needed, if it's needed, please unzip the attached hotfix Optimization.zip to override existing Optimization folder within the CodeWarrior PA installation folder. there will be present C:\Freescale\CW_PA_v10.5.1\eclipse\Optimization\resources\QorIQ\DDR\templates\init\errata_A009942.py

Confirm the general guide as below:

creating a new QCVS project

  - choose "Auto configuration" and "Discrete DRAM"

  - DRAM Speed Rating = Max speed                  (e.g., max 3200 MT/s, see datasheet).     

  - "Output data rate" choose "xxx MT/s"           (Current working speed, e.g. 1300MT/s, this data rate must match the DRAM speed configured in RCW image)

  - "Rank/Chip select" choose "x"                  (single CS or dual CS)

  - "tCL" choose "xx"                              (according to speed bin table in DRAM data sheet)

  - "DRAM configuration per device" choose "xx"    (see DRAM data sheet)

  - fill the proper CLK-to-QDS skews               (measure lengths of CLK and DQS signals via EDA tool, CLK length - DQS length)

CLK length minus DQS length, example:

CLK-to-DRAM0 length = 100 mm

CLK-to-DRAM1 length = 101 mm

DQS[0] length = 75 mm

DQS[1] length = 110 mm

CLK-to-DQS[0] skew = 100 mm - 75 mm = 25 mm

CLK-to-DQS[1] skew = 101 mm - 110 mm = -9 mm 

- CLK trace length must be equal to or longer than DQS trace length within 10 inches.

- If MCK trace length is shorter than DQS trace length, it must be within 2.0 inches.

DQ mapping - Controller pins:

If DQ bit swapping is used on your actual board, user must configure this in QCVS to match the actual PCB layout.

TIMING_CFG_1_and_3:

  - tCL/tRCD/rRP/tRAS  this value refers to DRAM datasheet to match the current working speed rate.

  - tWR (Write Recovery Time, Last data to precharge minimum interval), this value refers to DRAM datasheet.

  - tRRD(Activate-to-activate interval) this value refers to DRAM datasheet.

TIMING_CFG_2:

  - tFAW(Four Activate Window), this value refers to DRAM datasheet.

user should ensure those board-specific and DRAM-specific configurations match the actual hardware.

for other most of options, use the default QCVS preset value.

Thanks

[dbevans42]

I am currently working with my procurement to get NDA in place so that I can get full errata documentation.  However, I am using component T1042NXE7MQB and Google/NXP forum search seems to suggest that errata A009942 applies.

Can you please provide the referenced "Optimization.zip," I do not see it attached anywhere.

[June_Lu]

Please input the command after you read out the RCW status registers.

Please share the full ccs log to me instead of the command " ccs::reset_to_debug" result, such as

"I get a message that says "Library not found.""

The full log start from the first command you use the ccs.

Thanks

[dbevans42]

Attached is a .txt with the RCW output.  I ran the command you specified "ccs::reset_to_debug" at the end and it did not give the "library not found" message, but it did not display any other info.

I have also done a similar capture for the DDR config registers and attached that.  I cannot find anything wrong.  In fact these values used with GreenHills probe actually seem to pass and get D_INIT to clear, however D_INIT does not clear when I use the same values with QCVS tool.  I'm not sure what the difference is between using GH probe vs CWTAP.  I'd appreciate any ideas.

[db16122]

ACE error is automatic calibration error which is set if the memory controller detects an error during its training sequence. So if you lower the clock speed from 800MHz, how about the training result?

Meanwhile for 64bit or 32bit bus width, which one is selected to use for DDR4? how many pcs DDR4 is planed to connect to T1042

[dbevans42]

The memory controller is now set for 650MHz or 1300MT/s operation.  Same result.  We are attempting to use 32-bit mode for DDR4 because there is unintended bit swap on byte 8 of 64-bit interface (mistaken swap between nibbles).  The design was intended to be 64-bit + ECC but we are attempting to run 32-bit + ECC as a temporary  workaround.  That means that we currently have 5x 16-bit chips connected but are hoping to operate using only 3 of them.

I've tried many combinations of settings but nothing seems to change behavior in QCVS tool.  What is a bit odd is that I have also tried using a GreenHills emulator with similar values to QCVS in its startup script and I get past the wait loop for DDR_SDRAM_CFG_2[D_INIT] to clear, implying initialization is completing.  Then it fails on initial write/read verification with all 0x00 which makes sense since it is using suboptimal write leveling values.  I do not understand why the QCVS tool has different behavior.

[db16122]

Not sure DDR4 has 64BIT BUS WIDTH product. Do you mean LPDDR4?

[dbevans42]

It is DDR4.  This is a discrete design, not DIMM, so we have five 1G x 16-bit devices (64-bit + 8-bit ECC).

[db16122]

what the lowest clock freq to make the initialization work? Or the initiliazaion can not work at all. Have you check the schematics and layout based on hardware guideline? It would be helpful if you share the DDR4 part number to better review

[June_Lu]

Could you please confirm whether the CS0 in your description refers to D1_MCS0_B?

Please in your ccs run the command and update the full ccs log.

(bin)  % ccs::reset_to_debug

Thanks

[dbevans42]

Correct, I am referring to D1_MCS0_B.

When I run command

(bin)  % ccs::reset_to_debug

I get a message that says "Library not found."

[dbevans42]

Hello June,

Thanks for the reply.  I was able to use CCS to read the RCW status registers and confirm the RCW is programmed as expected.

I am using discrete DDR4 and have been through the user guide and layout considerations.

I have confirmed that we have a 650MHz clock for operation at 1300MT/s to satisfy Errata A-007864 for using a 32-bit interface.  A colleague suggested checking that the chip select is toggling.  I found that once the QCVS tool starts sending the configuration to the processor, the CS0 signal is held sufficiently low.  After programming is complete and it attempts to run the validation routine the CS0 signal is no longer being fully asserted.  I independently using a JTAG boundary scan tool to confirm that the signal is connected as expected and that the T1042 I/O can drive the net low enough to satisfy the VIL for the DDR4 memory device.  I also confirmed the net looks good in terms of routing for signal integrity and that it is not shorted to anything.  It seems that there is something about the memory controller configuration that is not allowing the chip select signal to function correctly.  Any other ideas?  Thank you.