Hi,
I am trying to run the operational DDR tests on a completely new custom board.
I've created a new configuration project, and given it the processor and DDR information ( We are using an ISSI part IS43TR16128CL-125KBLI)
I've been through the Pin Muxing configuration and assigned the module relevant to our board, and have made sure to select the correct reset request, (we are using pin 17)
In the component inspector for DDRmmc1, under the validation tab I have chosen all tests in the "Choose tests" tab, and when running the Operational DDR tests scenario the tests fail.
In the logs I get the following message:
#################### Result for: dma ###### Run 1 #################################################
Test result: [
Traceback (most recent call last):
File "C:\Freescale\CW4NET_v2019.01\Common\QCVS\Optimization\resources\QorIQ\ARMv8/ddr/run_core.py", line 571, in run_core_script
sys_init.init(params, session)
File "C:\Freescale\CW4NET_v2019.01\Common\QCVS\Optimization\resources\QorIQ\ARMv8\ddr\sys_init.py", line 136, in init
reset_out = utils.gdb_execute("cw_reset %d" % reset_delay)
File "C:\Freescale\CW4NET_v2019.01\Common\QCVS\Optimization\resources\QorIQ\ARMv8\common\utils.py", line 215, in gdb_execute
raise gdb.GdbError("ERROR: " + str(ex))
GdbError: ERROR: Target reset failed.
//
Additional error details:
[CCS: timeout during target operation]
]
I am using CodeWarrior Development Studio for QorIQ LS series - ARM V8 ISA Version: 11.4.0.
Any help would be greatly appreciated,
Many thanks,
Nic
Solved! Go to Solution.
There is problem at reset_to_debug, probably there is problem with JTAG hardware design on your target board.
The common on-chip processor (COP) requires the ability to independently assert PORESET_B and TRST_B to fully control the processor. If a JTAG/COP port is used, follow the JTAG/COP interface connection recommendations given in the chip's data sheet. If the JTAG interface and COP header are not being used, NXP recommends that TRST_B be tied to PORESET_B so that TRST_B is asserted when PORESET_B is asserted, ensuring that the JTAG scan chain is initialized during the power-on reset flow. See the JTAG configuration signals section in the chip's data sheet for more information.
Please refer to "Figure 17. JTAG interface connection" in AN5192.pdf.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hello Nicholas Hooper,
First please check whether there is valid RCW on the target board.
Please configure your target board as hard-coded RCW through cfg_rcw_src. The reset configuration word (RCW) source input, cfg_rcw_src, is multiplexed on CLK_OUT. This configuration input selects the source for the RCW data as shown in the following table.
Then check whether there is problem to reset the custom board when run QCVS DDRv validation.
In addition would you please capture the low level CCS console log to me to do more investigation?
When you connecting to the target board, the CCS console will be invoked automatically at the right bottom of the Windows task bar, please type "log v", then connect to the target board to do DDR validation again, the low level CCS log will be captured in the CCS console.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi Yiping,
Thanks for your support,
I have tried as you have asked and I have made the input to cfg_rcw_src 0.
I have run the tool again and I have the output from the ccs console here:
(bin) 1 % log v
CCS Windows Release Build 479.0.0.181125-p0
verbose logging
CCSAPI connection #1 accepted from LAPTOP-9DM9HV27 at Wed Mar 27 16:29:58 2019
check_min_version(serverh=0,*version)
api version: 00000004 00000006
ccs_get_cc_config(*config_string, count)
ERROR(23): CC not present
setup_cc(serverh=0,config_string= cwtap )
*** unhandled(command=169) ***
config_server(config_reg=0,config_data=0x000027F6)
get_config_chain(serverh=0,cc=0)
config_chain(serverh=0,cc=0,count=3,*devlist,*generic)
devlist: dap,ls1043a,sap2
get_config_chain(serverh=0,cc=0)
config_template(coreh.{serverh=0,cc_index=0,chain_pos=1},config_reg=4097,config_data=0x00001B58)
reset_to_debug(serverh=0,cc=0)
ERROR(39): Subcore error encountered during multicore operation
parse_error_ext(coreh.{serverh=0,cc_index=0,chain_pos=0}, 39)
error: LS1043A: Core not responding
get_subcore_error(serverh=0,cc=0,*error,*chain_pos)
error: Core not responding
chain_pos: 1
delete_cc(serverh=0,cc=0)
CCSAPI connection #1 from LAPTOP-9DM9HV27 closed at Wed Mar 27 16:30:09 2019
CCSAPI connection #1 accepted from LAPTOP-9DM9HV27 at Wed Mar 27 16:30:12 2019
check_min_version(serverh=0,*version)
api version: 00000004 00000006
ccs_get_cc_config(*config_string, count)
ERROR(23): CC not present
setup_cc(serverh=0,config_string= cwtap )
*** unhandled(command=169) ***
config_server(config_reg=0,config_data=0x000027F6)
get_config_chain(serverh=0,cc=0)
config_chain(serverh=0,cc=0,count=3,*devlist,*generic)
devlist: dap,ls1043a,sap2
get_config_chain(serverh=0,cc=0)
config_template(coreh.{serverh=0,cc_index=0,chain_pos=1},config_reg=4097,config_data=0x00001B58)
reset_to_debug(serverh=0,cc=0)
ERROR(39): Subcore error encountered during multicore operation
parse_error_ext(coreh.{serverh=0,cc_index=0,chain_pos=0}, 39)
error: LS1043A: Core not responding
get_subcore_error(serverh=0,cc=0,*error,*chain_pos)
error: Core not responding
chain_pos: 1
delete_cc(serverh=0,cc=0)
CCSAPI connection #1 from LAPTOP-9DM9HV27 closed at Wed Mar 27 16:30:23 2019
CCSAPI connection #1 accepted from LAPTOP-9DM9HV27 at Wed Mar 27 16:30:25 2019
check_min_version(serverh=0,*version)
api version: 00000004 00000006
ccs_get_cc_config(*config_string, count)
ERROR(23): CC not present
setup_cc(serverh=0,config_string= cwtap )
*** unhandled(command=169) ***
config_server(config_reg=0,config_data=0x000027F6)
get_config_chain(serverh=0,cc=0)
config_chain(serverh=0,cc=0,count=3,*devlist,*generic)
devlist: dap,ls1043a,sap2
get_config_chain(serverh=0,cc=0)
config_template(coreh.{serverh=0,cc_index=0,chain_pos=1},config_reg=4097,config_data=0x00001B58)
reset_to_debug(serverh=0,cc=0)
ERROR(39): Subcore error encountered during multicore operation
parse_error_ext(coreh.{serverh=0,cc_index=0,chain_pos=0}, 39)
error: LS1043A: Core not responding
get_subcore_error(serverh=0,cc=0,*error,*chain_pos)
error: Core not responding
chain_pos: 1
delete_cc(serverh=0,cc=0)
CCSAPI connection #1 from LAPTOP-9DM9HV27 closed at Wed Mar 27 16:30:36 2019
CCSAPI connection #1 accepted from LAPTOP-9DM9HV27 at Wed Mar 27 16:30:39 2019
check_min_version(serverh=0,*version)
api version: 00000004 00000006
ccs_get_cc_config(*config_string, count)
ERROR(23): CC not present
setup_cc(serverh=0,config_string= cwtap )
*** unhandled(command=169) ***
config_server(config_reg=0,config_data=0x000027F6)
get_config_chain(serverh=0,cc=0)
config_chain(serverh=0,cc=0,count=3,*devlist,*generic)
devlist: dap,ls1043a,sap2
get_config_chain(serverh=0,cc=0)
config_template(coreh.{serverh=0,cc_index=0,chain_pos=1},config_reg=4097,config_data=0x00001B58)
reset_to_debug(serverh=0,cc=0)
ERROR(39): Subcore error encountered during multicore operation
parse_error_ext(coreh.{serverh=0,cc_index=0,chain_pos=0}, 39)
error: LS1043A: Core not responding
get_subcore_error(serverh=0,cc=0,*error,*chain_pos)
error: Core not responding
chain_pos: 1
delete_cc(serverh=0,cc=0)
CCSAPI connection #1 from LAPTOP-9DM9HV27 closed at Wed Mar 27 16:30:50 2019
I have tried to look at debugging a project on the board and I am met with this error
Can you advise on what to do next?
Many thanks,
Nic
There is problem at reset_to_debug, probably there is problem with JTAG hardware design on your target board.
The common on-chip processor (COP) requires the ability to independently assert PORESET_B and TRST_B to fully control the processor. If a JTAG/COP port is used, follow the JTAG/COP interface connection recommendations given in the chip's data sheet. If the JTAG interface and COP header are not being used, NXP recommends that TRST_B be tied to PORESET_B so that TRST_B is asserted when PORESET_B is asserted, ensuring that the JTAG scan chain is initialized during the power-on reset flow. See the JTAG configuration signals section in the chip's data sheet for more information.
Please refer to "Figure 17. JTAG interface connection" in AN5192.pdf.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
i have solved the problem of mailbox will send tow package。when len <257.cause of hard bug
-Original-