JTAG Diagnostics

[连营张]

hello,

I'm currently trying to debug a p2041 with a CodeWarrior TAP but unfortunatly I am having some problems.

While using CodeWarrior Development Studio I get the error message:

JTAG Diagnostics

Starting Power at Probe test...

Test result: PASSED

Starting IR Scan test...

Error measuring IR length

i tested the TMS,TCK,finding that they toggle when a debugger operation is actively running.but i found that the TDO couldn't toggles at the SoC.What‘s the possible reasons ?thanks in advance.

[yipingwang]

Hello lianying zhang,

If the test fails to measure the length of the instruction register, Error measuring IR length is thrown.

The error might be due to one or more of the following reasons:

• TRST stuck low: This may hold the target JTAG logic in reset, preventing any shifts to occur.

• TMS disconnected or stuck: This may prevent the target from making any JTAG state changes.

• TCK disconnected or stuck: This may prevent any state changes or clocking of data.

• TDI disconnected or stuck: This may prevent the test pattern data from getting into the target.

• TDO disconnected or stuck: This may prevent the test pattern data from getting out of the target.

If the test fails, then it is possible that there is a physical connection problem with the JTAG pins, or the JTAG frequency is too high.

Please refer to JTAG interface Connection as the following.

Have a great day,
Yiping

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

[连营张]

hello,the  error was solved because i pulled the TRST to high.But I encountered a new problem,it says：failed to reset the target,core not responding.i checked the TCK pin,the clock is normal and the JTAG's power supply is also normal.What is the possible reason ?

[yipingwang]

Hello lianying zhang,

There should be no valid RCW on the target board now. Two options for you.

1. Use CodeWarrior JTAG configuration file to override RCW, please refer to the section "Setting up a remote system to use a JTAG configuration file" in C:\Freescale\CW_PA_v10.5.0\PA\Help\PDF\Targeting_PA_Processors.pdf.

2. Use hard-coded RCW.

If you still have connection problem, please capture the low level CCS log and send it to us to do more investigation.

Please enable CCS log from "Run->Debug Configurations -><project>-core0_RAM_-Connect(Download)->Edit...->Advanced->Advanced CCS setting->Enable logging", and connect to the target from "Run->Debug Configurations-><project>-core0_RAM_-Connect(Download)->Debug”, the CCS log will be displayed in the console panel in CodeWarrior IDE. (If the CCS log in the console is truncated, please enlarge the console buffer from Window->Preferences->Run/Debug->Console->uncheck "Limit console output". Please open the console panel from Window->Show View->Console, and if nothing displayed, please choose the correct session on the right top icon in the panel.)

Have a great day,
Yiping

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

[连营张]

I have tried the first method, but it is invalid.Then I first show you the ccs log:

[yipingwang]

Hello lianying,

Did you use CodeWarrior JTAG configuration file to override RCW on the target which I mentioned previously? Why I didn't find CCS writes RCW related registers in the CCS log? Or did you use hardcoded RCW?

Thanks,

Yiping

[连营张]

hello Yiping Wang,

        i used the hardcoded RCW（10101，Two (x2, x4) serial RapidIO at 2.5 GHz, 100-MHz ref clk, all agent mode; all cores in boot hold-off; dual

4-pin UARTs enabled; platform ratio of 8:1; core PLL ratio of 14:1）.i want to know whether"COP debugger needs the ability to drive HRESET and TRST independently"means that i must write a c program which detects the JTAG's COP_HRST_N and COP_TRST_N pins through the PIC microcontroller to achieve above timing wave form?

[yipingwang]

Hello lianying zhang,

The USB TAP generate the above TRST* and HRESET* signal timing when entering a dbugger RESET commands.

You could open CodeWarrior Connection Sever（CCS console) and enter the following low level commands:

% delete all

% config cc utap(if you use new product CodeWarrior TAP, please use ”config cc cwtap“)

% ccs::config_chain p2040

% ccs::reset_to_debug

Have a great day,
Yiping

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

[连营张]

it shows that p2040: Core not responding when i typed "ccs::config_chain p2040".

i means that my JTAG's several cop_* signals are all to PIC,not directly to p2041, then COP debugger has the ability to drive HRESET and TRST independently not by PIC？

[yipingwang]

Hello lianying,

In your previous CCS log, it seems that there is no problem at ccs::config_chain, probably there is RCW problem now.

COP debugger has the ability to drive HRESET and TRST independently, the debugger go through the PIC for reset signal.

You could refer to the schematics for the evaluation board.

Have a great day,
Yiping

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

[连营张]

hello Yiping Wang,i found that my board's JTAG interface Connection seems to be Incorrect.

.

The pictures above is from the evaluation board's material.the pwr_hrst_n signal is produced by the MAX6370,right?but unfortunately,my board hasn't the watchdog timer,there are other solutions to make up it or i must add a WDT?

[yipingwang]

1. Please check whether no problem with the CodeWarrior (USB) TAP, do you have a demo board to verify the TAP?

2. Please check JTAG interface hardware design on your target board, please ensure HRESET not tied to TRST, HRESET exclusive to COP/JTAG header.

Have a great day,
Yiping

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

[连营张]

hello,Yiping Wang

i have checked the TAP,it's ok. also,the HRESET is not tied to TRST.In addition, what reasons can lead to this situation？

[yipingwang]

Hello lianying zhang,

In your CCS log , there is no problem to get the configure chain to set up the basic connection to processor, it failed at ccs_reset_to_debug, so I suspected there was problem with HRESET and TRST. COP debugger needs the ability to drive HRESET and TRST independently, please refer to the following timing wave form.

Critical timing for USB TAP is the trailing edge of the HRESET* signal. TRST* must be negated in time for USB TAP to send several COP commands to the processor before HRESET* is negated. Processor control problems occur when the TRST* follows HRESET*.

With TRST* asserted, the JTAG lines are held in reset. This means the JTAG lines cannot be used to send COP commands to the target processor.  If the target processor does not receive the COP commands designed to stop when HRESET* is negated, the processor will begin executing target code instead.

So I suggest you check HRESET and TRST according to the above JTAG connection diagram.

Have a great day,
Yiping

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

[连营张]

hello,Yiping Wang,The above two pictures are respectively JTAG's interface and cpu.The top picture’s several reset pins（COP_TRST_N,COP_SRST_N,COP_HRST_N） are all connected to PIC Microcontrollers,while cpu's CPU_TRST_N pin is also connected to  PIC Microcontrollers,they aren't connected directly to each other.if it is like this,how the jtag can reset the cpu core?it is the reason that leads to" failed to reset the target,core not responding"？Looking forward to your reply！