topic Re: CodeWarrior Error measuring IR length in P-Series

CodeWarrior Error measuring IR length

martinolsson — Fri, 12 Dec 2014 10:22:31 GMT

Hello,

I'm currently trying to debug a MVME2502 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

And then the debugging quits.

In your manual (CodeWarrior Development Studio for Power Architecture Processors Targeting Manual) I read that:

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.

So i checked the conector and its working fine. I also asked Artesyn about their manual having an error (the

TDI and TDO on the COP Connector had switch places) and they replied that it was a simple missprint.

I also verified my JTAG frequency in CodeWarrior Development Studio running at 10230kHz. So hopefully

it's not the frequency running to high.

So now I'm at a loss here, I don't really know what to do next.

If I have forgotten any vital information about my setup just ask.

//Martin

Re: CodeWarrior Error measuring IR length

lunminliang — Wed, 17 Dec 2014 08:03:42 GMT

I think it's worthy of trying a lower JTAG frequency.

Do you have only one core or more core checked in CodeWarrior debugger?

Re: CodeWarrior Error measuring IR length

martinolsson — Thu, 18 Dec 2014 08:29:04 GMT

Hello lunminliang,

Sorry for the slow awnser, I have now tried to lower myJTAG frequency to 4000 and 10 kHz but it did not

solve my problem.

On the second question i currently have one core selected under Debug Configuration>Target settings (e500v2-0).

//Martin

Re: CodeWarrior Error measuring IR length

yipingwang — Thu, 18 Dec 2014 11:35:52 GMT

Hello Martin Olsson,

CodeWarrior TAP with the probe tips(CWH-CTP-COP-YE) doesn't support your target board, for details please refer to http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CW_TAP&fsrch=1&sr=3&pageNum=1.

Probe tip for PowerQUICC II/III, QorIQ MPUs: CWH-CTP-COP-YE
Probe tip for StarCore DSPs: CWH-CTP-STC-YE
QorIQ LS processor (Coretex 10 pin) CWH-CTP-CTX10-YE

This is should JTAG hardware compatible problem with your target board.

Have a great day,
Yiping

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

Re: CodeWarrior Error measuring IR length

martinolsson — Thu, 18 Dec 2014 11:58:17 GMT

Hello Yiping Wang,

I'm sorry but i don't understand. My card is a MVME2502 and its spec is

Processor  Freescale QorIQ P2020 (dual-core) <-----------------

 1000 MHz to 1.2 GHzcore frequency

 512 KB L2 cache

....

and it comes with a standard COP header.

And the supported devices on CWH-CTP-COP-YE is

Supported Devices

QorIQ Qonverge B Series
QorIQ Qonverge BSC Series
PowerQUICC II (82xx)
PowerQUICC II Pro (83xx)
PowerQUICC III (85xx)
QorIQ Communications Processors Value-Performance Tier
QorIQ Communications Processors Mid-Performance Tier
- P2020: QorIQ P2020/10 Single- and Dual-Core Communications Processors <------------------------
- P2040: QorIQ P2040/P2041 Quad-Core Communications Processors with Data Path
- P3041: QorIQ P3041 Quad-Core Communications Processors with Data Path
- T2080: QorIQ T Series T2080/T2081 Eight Virtual Core Communications Processors
QorIQ Communications Processors High-Performance Tier

From what i understand P2020 is supported? Or are you refering to something else?

//Martin

Re: CodeWarrior Error measuring IR length

yipingwang — Mon, 22 Dec 2014 09:32:06 GMT

Hello Martin Olsson,

P2020 processor is supported by CodeWarrior TAP.

I think the problem should be caused by JTAG hardware design on your target, please refer to e500 "JTAG interface connection" diagram in page 98 of http://www.freescale.com/files/32bit/doc/data_sheet/MPC8560EC.pdf.

Please pay attention to TRST, TMS, TCK, TDI and TDO.

Have a great day,
Yiping

Re: CodeWarrior Error measuring IR length

martinolsson — Fri, 02 Jan 2015 14:01:12 GMT

Hello Yiping Wang,

I have gone through my connections on MVME2502 and found that on pin-12 there is a COP Present that is pulled up. I connected pin-12 to ground and finaly managed to connect to core 0 in CodeWarrior Development Studio.

But now I'm getting another error, though very similar. Error testing IR scan and not Error measuring IR length.

JTAG Diagnostics

Starting Power at Probe test ...

Test result: PASSED

Starting IR Scan test ...

Error testing IR scan

I checked my connections (TDO, TDI, TRST, TCK, TMS) with a oscilloscope and they are working fine.

Before I connected pin-12 I didn't get anything on pin-1 (TDO), but now I'm getting something (I have no idea if it's the right data though). I also tried changing clock speed in JTAG settings again as Lunminlang suggested with no succes.

Could it be that e500 is not doing the test as CodeWarrior Development Studio wants it to?

In "CodeWarrior Development Studio for Power Architecture Processors Targeting Manual" it says that:

The test compares the TDO data it captures against the TDI test pattern it sent to see if TDO contains the test

pattern. It expects to find the test pattern in the TDO, but bit-shifted to the left by some number of bits (corresponding to the IR length).

If it fails to find the test pattern, then the test reports an error, Error testing IR scan.

Is there a way for me to make it succed in bit-shifting? Or is it OK for CodeWarrior Development Studio to only get an error in this stage?

//Martin

Re: CodeWarrior Error measuring IR length

yipingwang — Sun, 04 Jan 2015 10:31:13 GMT

Hello Martin Olsson,

Please make sure there is only one device on the JTAG chain, otherwise you need to configure CodeWarrior JTAG configuration file for bypass.

Please configure valid SYSCLK while running scan testing.

Please ensure CPU_TRST is asserted during POR and is deasserted during the JTAG testing.

Please refer to P2020 Reference manual for the section "JTAG test signals-details".

JTAG interface works in accordance with IEEE 1149.1.

TAP state machine is controlled by TMS signal. Every TCK clock causes a step to next state depending on TMS.

Thanks,

Yiping

Re: CodeWarrior Error measuring IR length

martinolsson — Fri, 16 Jan 2015 10:42:59 GMT

Hello Yiping,

Thanks for all your time and help. Unfortunately I gave upp on making Codewarrior IDE work without "Error testing IR scan" and moved into GDB insted.(following text is for people who also want to make it work with the same card)

So i used the p2020_init and some xml that was also needed witch i found in gdb_test_ccs_365 file (from your download page) and modified the p2020 file into this:

# Workaround to send g-packet of correct size on "target remote"

echo Loading basic powerpc register info\n

set tdesc filename ...\gdb_test_ccs_365\xml\e500v2.xml

echo Connecting to proxy\n

target remote xxx.xxx.xxx.xxx:2345

mon jtag_chain mpc8572

# proxy will keep g-packet size info

kill

echo Loading e500v2 register info\n

set tdesc filename ...\gdb_test_ccs_365\xml\e500v2.xml

# gdb settings

set debug remote 0

set logging off

set debug frame 0

set remotetimeout 20

set remote hardware-breakpoint-limit 2

echo Connecting to proxy\n

target remote xxx.xxx.xxx.xxx:2345

#mon ccs_host xxx.xxx.x.xxx

#mon ccs_path ...\bin\ccs.exe

echo Setting jtag speed\n

mon jtag_speed 10000

mon jtag_chain mpc8572

mon jtag_chain

echo Connecting to probe and target\n

mon connect

mon jtag_chain

mon chain_pos 0

mon jtag_chain

mon chain_pos 1

echo Jtag speed\n

mon jtag_speed

mon get_probe_status

echo Reset\n

mon reset system

echo Initialize COP register\n

set $copcr=0x0000000000040200

echo Update register cache\n

flushregs

monitor mem_access ijam

define e500v2_workaround

echo e500v2 workaround \n

mon chain_pos $arg0

mon chain_pos

echo Initialize program and debug interrupt vectors\n

set $ivpr=0xFFFF0000

# debug - (a valid instruction should exist to be fetched)

set $ivor15=0x0000F000

# program

set $ivor6=0x0000F700

echo Insert hw breakpoint at reset address\n

set $iac1=0xfffffffc

set $dbcr0=0x40800000

set $dbcr1=0x00000000

# activate debug interrupt and enable SPU

set $msr=0x02000200

echo Run target\n

monitor no_wait_continue

echo Wait 10 sec\n

shell timeout /t 10

echo Stop target\n

monitor stop

echo Remove hw breakpoint at reset address\n

set $dbsr=0x01CF0000

set $dbcr0=0x41000000

set $iac1=0x00000000

end

p /x $pc

e500v2_workaround 1

p /x $pc

Note: This is for windows. ( shell timeout /t 10) and my test is full of buggs. I need to run this three times befor i get it to work proper.

After that it is straight forward.

<gdb> file Myfile

<gdb> break main

<gdb> set follow-fork-mode child

<gdb> c

load and start the program on the MVME2502. And it will halt in main. And then i can step through it.

Note: The MVME2502 had a COP present pin on PIN 12 that NEEDS to be pulled to ground or it wont work at all. (See former awnsers)

I still have some minor errors that I haven't worked out yet but they aren't that big.

Thanks again for all your hard work,

Martin