D_INIT not cleared

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

D_INIT not cleared

3,780 Views
jboggs
Contributor II

I’m having problems running the CodeWarrior Validation tool on custom hardware.  I'm using a T1040 with Smart Modular SHI2047SO410872SC, 2Gx72, DDR4.  I have the tool set to read from the SPD.  I get the following error when I try to run a validation:

--------------------------------------------------------------------

Exception: (<<Error configuring the target! - DDR initialization failed: D_INIT was not cleared by hardware!>>)

--------------------------------------------------------------------

Target system was initialized 0 times and it took 0.000000 seconds.

Target system effective test execution took 0.000000 seconds.

 

I've reviewed several records related to this same problem, none of which seem to have been resolved, including:

https://community.nxp.com/thread/441234

https://community.nxp.com/thread/447035

https://community.nxp.com/thread/485084

https://community.nxp.com/thread/485084

https://community.nxp.com/thread/467088

 

Based on what I have read, I checked the settings in the Properties page, and everything seems correct. 

I tried tying HRESET from the TAP to the reset pin of the DDR which did not resolve the issue. 

I know the hardware design is correct because the board boots and the code runs from DDR properly. 

One thing I am concerned about is the fact that the System Clock (SCLK) is set to 100MHz and Memory Clock (DDRCLK) is set to 100MHz on the Processor Properties page.  My design does not have a clock connected to SYSCLK or DDRCLK.  I don't know if that is causing the problem, but I don't know how to change those settings.   

 

 Anyone  ?!?!?!?!?!

 

0 Kudos
18 Replies

2,787 Views
jboggs
Contributor II

That did it !!!

Along with the DDR_WRLVL_CNTL registers I had to change the DDR_TIMING_CFG_n, DDR_SDRAM_CFG_n, DDR_SDRAM_CLK_CNTL, DDR_DQ_MAP0 registers. Now the test has started. Thank you so much for your assistance in resolving this issue. 

0 Kudos

2,787 Views
jboggs
Contributor II

I’m glad to see you haven’t given up. I have attached the console output from U-Boot in the “U-BootStart.txt” file.

I created a Bareboard project as you suggested, with an Attach launch configuration. I booted the board to U-Boot, in the debugger I was able to read the DDR registers after clicking the suspend button. In the Registers window I right clicked on the DDR registers heading and choose “copy Registers”, I pasted the result in the file named “DDR_Regs_copy_from_U-Boot.txt” which is attached.

I also clicked the Export button, I had the Include register information choice selected for the export. The result of the export is captured in the file named “U-Boot_DDR_withInfo.regs” which is also attached. I wasn’t sure which output format would be easier for you to look at so I included both.

0 Kudos

2,787 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

In the attached DDR registers value captured from U-BOOT, DDR_WRLVL_CNTL register is 0xc675f606, however in your previous DDR CCS log, DDR controller register DDR_WRLVL_CNTL is initialized with 8655F605, this value is not correct, which causes the error "D_INIT not cleared".

Please use the DDR controller configuration parameters captured from u-boot in the QCVS DDRv tool to initialize DDR controller to do DDR validation.

In the QCVS DDRv project, please export DDR controller registers to a .regs file, please compare these registers values with the setting captured from u-boot, and modify register values setting in the .regs file and import it back to the QCVS project, then start DDR validation again.

Thanks,

Yiping

0 Kudos

2,787 Views
jboggs
Contributor II

Yes the application code runs properly out of DDR.

It seems unlikely that any of the data lines are actually stuck at zero or one as I’m able to run the board code successfully out of DDR. While it’s possible that an address line is stuck at zero on one, again it seems unlikely because the board code runs correctly out of DDR. The results that I sent to you I obtained by booting the board into U-Boot and the using codeWarrior to Attach to the board.

0 Kudos

2,787 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

Sorry for the late reply.

1. Please booting the board into U-Boot and stop it at the prompt "=>", please attach the u-boot console log to me.

2. Please create a bareboard project from File->New->CodeWarrior Bareboard Project Wizard, in the Debug Target Settings panel, please only select "Attach" Launch configuration.

Please connect to the target board with "<project>-core00_RAM_T1040_Attach" after u-boot stopping at "=>".

3. If the debugger cannot suspend u-boot execution automatically, please click the "suspend" button manually, please read DDR values from Registers panel. Please refer to the attached screenshot, if your problem remains, please capture similar screenshot to me to do more investigation.

Thanks,

Yiping

0 Kudos

2,787 Views
jboggs
Contributor II

I ran the DDR test, the results from the console window are attached. As before every read seems to return a value of zero.

When I use the Attach type debug session, the DDR registers, in fact all registers show “Register not accessible at runtime.” In the value column.

0 Kudos

2,787 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

The Walking Ones detects these memory faults:
• Address Line: The board or chip address lines are shorting or stuck at 0 or 1. Either condition could result in
errors when the hardware reads and writes to the memory location. Because this error occurs on an
address line, the data may end up in the wrong location on a write operation, or the hardware may access
the wrong data on a read operation.
• Data Line: The board or chip data lines are shorting or stuck at 0 or 1. Either condition could result in corrupted values as the hardware transfers data to or from memory.
• Retention: The contents of a memory location change over time. The effect is that the memory fails to retain
its contents over time.

Again, please confirm your original description? Can you run your code(program) in DDR successfully?

If yes, please run your program first, then use CodeWarrior to Attach to your target board.

Thanks,

Yiping

0 Kudos

2,787 Views
jboggs
Contributor II

I am trying to get a dump of DDR registers as you requested.  I set up a bare board Attach configuration, which links to the board OK, but when I open the Registers window, all of the registers under the DDR have "Register not accessable at run time." listed in the Value column. 

0 Kudos

2,787 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

In the Hardware Diagnostics panel, please select "Memory Test" to perform three hardware tests, Walking Ones, Bus Noise, and Address.

As you mentioned  originally "the board boots and the code runs from DDR properly", how did you run your code? Boot from NOR flash or with CodeWarrior tool? Have you already run your code in DDR successfully? If yes, the DDR controller should be initialized properly with your code. 

So please run your code in DDR  first, then use CodeWarrior to "Attach" to your target board to read DDR controller configuration registers values.

Thanks,

Yiping

0 Kudos

2,787 Views
jboggs
Contributor II

I tried using the hardware diagnostics tool as you suggest, and I’m not sure how to interpret the results.

The first thing I did was modify the T1040RDB_init_core.tcl file as you suggested. I also eliminated all references to CPLD and NAND flash as my board does not have those devices. When the debugger connects it comes back with what appears to be an error message as seen in the DebugConnection.jpg file attached. I was able to set up a hardware diagnostic action but again the result is somewhat confusing. Read of any address always returns a zero value, even if I attempt to write to the address location first. The console seems to indicate that the write process worked. The console message is as follows:

Writing to target...

Wrote 0x12345678 at address: 0x04000000

Task Execution finished. Disconnecting ...

 

Similarly for a read the console output is:

Reading from target...

Read 0x00000000 at address: 0x04000000

Task Execution finished. Disconnecting ...

 

I have attached a shot of the Hardware Diagnostics Action window as well named DiagActionWindow.jpg.  

I will get the register dump to you shortly.

JB

0 Kudos

2,789 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

 

As you mentioned previously the board boots and the code runs from DDR properly, would you please capture DDR controller configuration registers values when running your code with CodeWarrior?

 

Please create a CodeWarrior bare board project following new project wizards in CodeWarrior IDE, please select "Attach" launch configuration in Debug Target Settings panel.

After run your code on your target board, please connect CodeWarrior to your target board from Run->Debug Configurations-><project>-core00_RAM_T1040_Attach->Debug.

Then open reading registers panel from Window->Show View->Other->Debug->Registers, please copy and save DDR controller registers. (Please also send these register values to me, I will compare this configuration with the setting in your  QCVS project).

 

In the QCVS DDRv project, please export DDR controller registers to a .regs file, please compare these registers values with the setting captured with CodeWarror, and modify register values setting in the .regs file and import it back to the QCVS project.

 


Have a great day,
TIC

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

0 Kudos

2,789 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

In your CCS log, DDR_ERR_DETECT(0x00008E40) is read as 0x80, DDR_ERR_DETECT[ACE] is set.

For DDR_ERR_DETECT[ACE] can be set due to the following reasons:

  1. The training sequence that the controller follows to calibrate the read data path was not able to complete. This would probably only happen if there was a hard failure on the memory interface caused by board-level issues or incorrect controller settings.
  1. Incorrect termination of MDICx signals.
  1. Write leveling calibration was not able to complete. This relates to improper settings of the DDR_WRLVL_CNTL register or board-level issues.

You are using the DDR controller configuration parameters from the SPD, as normal there should be no problem with DDR controller configuration parameters.

I suggest you perform DDR hardware diagnostics.

CodeWarrior provides DDR hardware diagnostics function, please refer to the section "11.3.2 Working with Hardware Diagnostic Action editor" in Freescale\CW_PA_v10.5.1\PA\Help\PDF\Targeting_PA_Processors.pdf.

First please click "C/C++", then create a bareboard CodeWarrior project with "Connect" launch configuration enabled, please modify DDR configuration section in the initialization file in <project_folder>/CFG/T1040RDB_init_core.tcl according to the file ddrCtrl_1.tcl under Generated_Code folder in the QCVS DDRv project. Then connect to the target board to do DDR hardware diagnostics according the user manual.


Have a great day,
TIC

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

0 Kudos

2,789 Views
jboggs
Contributor II

The log file from the start of a Centering the clock validation is attached. I let the tool run through the first three attempts which failed all three times.  

When I read the DDR_ERR_DETECT register in the debugger I get an error saying “error reading memory”, for all DDR registers. If I set the debugger to initialize the target I read 0x0000000 as a value for the DDR_ERR_DETECT register, I don’t know if the debugger initialization process is changing that reading however.

0 Kudos

2,789 Views
jboggs
Contributor II

Here is what I got when I reconfigured my board for default RCW 0x9e. 

(bin) 1 % log v

CCS Windows Release Build 439p0

verbose logging

CCSAPI connection #1 accepted from “Redacted” at Wed Jan 30 11:30:40 2019

check_min_version(serverh=0,*version)

api version: 00000004 00000006

available_connections(serverh=0,*count,*cc)

connections: {0,73,0xa9fea6cb}

cc_version(serverh=0,cc_index=0,index=0,*version)

config_chain(serverh=0,cc=0,count=1,*devlist,*generic)

devlist: t10xx

reset_to_debug(serverh=0,cc=0)

available_connections(serverh=0,*count,*cc)

connections: {0,73,0xa9fea6cb}

get_config_chain(serverh=0,cc=0)

*** unhandled(command=163) ***

write_memory(coreh.{serverh=0,cc_index=0,chain_pos=0},

addr.{addr_hi=0x00030000,addr_lo=0x00118008,size=1,space=0},count=1,*data)

data: 80

read_memory(coreh.{serverh=0,cc_index=0,chain_pos=0},

addr.{addr_hi=0x00030000,addr_lo=0x00118008,size=1,space=0},count=1,*data)

data: 80

CCSAPI connection #1 from “Redacted” closed at Wed Jan 30 11:30:42 2019

(bin) 2 %

0 Kudos

2,789 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

In fact, when you click "Target Connection" in the DDRv Tool, the CCS log should be like the section which you captured. DDRv Tool just does 2Cx_I2CCR register (0x00118008) writing and reading check, and in your CCS log the checking result is correct, no problem.

Please refer to the attached screenshot for DDRv tool, please click "Start Validation", then capture the CCS log and attach it to me do more investigation, this section CCS log starts form LAW initialization. I guess there is problem to write some specific DDR configuration register which causes "D_INIT" error.

When the "D_INIT" error occurs, please keep the current target board environment and read DDR_ERR_DETECT register value as I mentioned previously.

In addition, would you please zip the workspace for your QCVS project and attach it? I do some verification on my target to check whether there is obvious DDR configuration problem.


Have a great day,
TIC

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

0 Kudos

2,789 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

First of all, please fill "DDR Bus Clock" in Properties panel in DDRv tool according to your target board.

Please refer to RCW[DDR_REFCLK_SEL] to check DDR reference clock selection for DDR PLL.

Options:
00 The DDRCLK pin provides the reference clock to the DDR PLL
01 DIFF_SYSCLK/DIFF_SYSCLK_B provides the reference clock to the DDR PLL

Please refer to RCW[MEM_PLL_RAT] to get Memory controller complex PLL multiplier/ratio to calculate DDR Date Rate.

In addition, would you please capture the CCS log to me to do more investigation?

When you use DDRv tool to connect to the target board, CodeWarrior connection Sever will be invoked automatically, please open it at the right bottom of the task bar, then type command "log v" in CCS console. In CodeWarrior IDE, please connect to the target board again, the low level communication log between DDRv and the target board will be captured in the CCS console.


D_INIT bit will be automatically cleared by hardware once the DDR controller initialization is completed. Please read the value of DDR_ERR_DETECT in CodeWarrior IDE to check whether ACE bit is set.

In CodeWarrior IDE, please click "C/C++" to replace QCVS at the right top of CodeWarrior IDE, then create a bareboard project from File->New->CodeWarrior Bareboard Project Wizard, please select "Attach" Launch configuration in the "Debug Target Settings" panel,  please connect the target board from Run->Debug Configurations-><project>-core00_RAM_T1040_Attach.

Then read DDR_ERR_DETECT register value  from Windows->Show View->Other->Debug->Registers->DDR.


Have a great day,
TIC

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

0 Kudos

2,789 Views
jboggs
Contributor II

TIC:

DDR Bus Clock is set to 800MHz.

RCW, DDR_REFCLK_SEL is set to “01” to select DIF_SYSCLK / DIF_SCLK_B as the DDR reference clock, which is constant with board hardware.  This is one of my concerns.  The Processors properties page show Memory Clock (DDRCLK) set to 100MHz, it will not take "0" as an input and I don't know howt to tell the tool that this clock is not present.  The DDRCLK pin of the T1040 is grounded on my board. 

RCW, MEM_PLL_RAT is set to 01_0000 for 16:1 multiplier of the 100MHz clock or 1600 MHz rate.

The DDR_ERR_DETECT register value is reported as 0x00000000

Here is what was captured in the CCS console:

(bin) 1 % log v CCS Windows Release Build 439p0 verbose logging CCSAPI connection #2 accepted from “Redacted” at Mon Jan 28 12:16:46 2019 check_min_version(serverh=1,*version)   api version: 00000004 00000006 available_connections(serverh=1,*count,*cc)   connections: {0,73,0xa9fe0772} cc_version(serverh=1,cc_index=0,index=0,*version) config_chain(serverh=1,cc=0,count=1,*devlist,*generic)   devlist: t10xx reset_to_debug(serverh=1,cc=0) available_connections(serverh=1,*count,*cc)   connections: {0,73,0xa9fe0772} get_config_chain(serverh=1,cc=0) *** unhandled(command=163) *** write_memory(coreh.{serverh=0,cc_index=0,chain_pos=0},   addr.{addr_hi=0x00030000,addr_lo=0x00118008,size=1,space=0},count=1,*data)   data: 80 read_memory(coreh.{serverh=0,cc_index=0,chain_pos=0},   addr.{addr_hi=0x00030000,addr_lo=0x00118008,size=1,space=0},count=1,*data)   data: 80 CCSAPI connection #2 from “Redacted” closed at Mon Jan 28 12:16:48 2019 (bin) 2 %

Here is what was captured in the CCS console for a reconnect:

(bin) 1 % log v CCS Windows Release Build 439p0 verbose logging CCSAPI connection #2 accepted from “Redacted” at Mon Jan 28 12:16:46 2019 check_min_version(serverh=1,*version)   api version: 00000004 00000006 available_connections(serverh=1,*count,*cc)   connections: {0,73,0xa9fe0772} cc_version(serverh=1,cc_index=0,index=0,*version) config_chain(serverh=1,cc=0,count=1,*devlist,*generic)   devlist: t10xx reset_to_debug(serverh=1,cc=0) available_connections(serverh=1,*count,*cc)   connections: {0,73,0xa9fe0772} get_config_chain(serverh=1,cc=0) *** unhandled(command=163) *** write_memory(coreh.{serverh=0,cc_index=0,chain_pos=0},   addr.{addr_hi=0x00030000,addr_lo=0x00118008,size=1,space=0},count=1,*data)   data: 80 read_memory(coreh.{serverh=0,cc_index=0,chain_pos=0},   addr.{addr_hi=0x00030000,addr_lo=0x00118008,size=1,space=0},count=1,*data)   data: 80 CCSAPI connection #2 from “Redacted” closed at Mon Jan 28 12:16:48 2019 (bin) 2 %

 

 

0 Kudos

2,787 Views
yipingwang
NXP TechSupport
NXP TechSupport

Hello Johh Boggs,

In your CCS log, DDR controller configuration registers cannot be accessed at all.

Would you please configure your target board as hard-coded RCW and use DDRv to connect to the target board to capture the CCS log again?

cfg_rcw_src[0:8] = 0_1001_1110 (0x9E)

Please refer to "4.6.5.1.1 Hard Coded RCW Options" in T1040 Reference Manual for details.


Have a great day,
TIC

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

0 Kudos