Hi
This might be a dumb question.
What is the output waveform of the TDI pin on the Jtag which is connected to the
target board? Sine wave or square wave?
Best regards
Peter
TDI output
Started by ●May 28, 2008
Reply by ●May 28, 20082008-05-28
Hello Peter,
On Tue, May 27, 2008 at 11:53 PM, wrote:
> Hi
>
> This might be a dumb question.
> What is the output waveform of the TDI pin on the Jtag which is connected to
> the target board? Sine wave or square wave?
Just to be clear - TDI [as in Test Data Input] on pin 3 of the 14 pin
header comes from the Emulator and is an input to the target.
This is a digital signal that goes from ground to about 3v. If you
look at it in relation to TCLK_RET [pin 9 - JTAG clock] you should be
able to determine if the signal is okay. You can use the '-g
0x55555555 -c' option in xdsprobe to generate a continuous pattern of
alternating bits.
Both signals should be 'clean square waves'.
The same holds true for TDO [as in Test Data Output from the target to
the emulator] on pin 7 with one major exception - when TDO quits
sending valid data [like between words] it "tristates" [or goes Hi-Z].
When this occurs, you will see what looks like a "capacitor discharge
ramp" [if the last bit was a '1'] or a small "capacitor charge ramp"
[if the last bit was '0']. This can extend over multiple clocks.
mikedunn
>
> Best regards
> Peter
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Tue, May 27, 2008 at 11:53 PM, wrote:
> Hi
>
> This might be a dumb question.
> What is the output waveform of the TDI pin on the Jtag which is connected to
> the target board? Sine wave or square wave?
Just to be clear - TDI [as in Test Data Input] on pin 3 of the 14 pin
header comes from the Emulator and is an input to the target.
This is a digital signal that goes from ground to about 3v. If you
look at it in relation to TCLK_RET [pin 9 - JTAG clock] you should be
able to determine if the signal is okay. You can use the '-g
0x55555555 -c' option in xdsprobe to generate a continuous pattern of
alternating bits.
Both signals should be 'clean square waves'.
The same holds true for TDO [as in Test Data Output from the target to
the emulator] on pin 7 with one major exception - when TDO quits
sending valid data [like between words] it "tristates" [or goes Hi-Z].
When this occurs, you will see what looks like a "capacitor discharge
ramp" [if the last bit was a '1'] or a small "capacitor charge ramp"
[if the last bit was '0']. This can extend over multiple clocks.
mikedunn
>
> Best regards
> Peter
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●May 28, 20082008-05-28
Hi Mike
I just read one of your artical about xdsprobe this morning, which is very helpful. I also found a TI document to get more details.
With your help, I am one step close to the truth. When I do the xdsprobe test, the system passes some basic tests. But, when it goes to the path-length test, the system starts to fail. The following is the test result. Could you please have a quick look. Do you know what might be going wrong? I am doing the 0x55555555 test right now. I can see the signal from TDI, which is not so consistent with the defined value. Still modifying the ccBrd0.dat file to get the correct result.
I have got the latest driver from wintech with the C672X support, which doesn't makes any difference.
\bin\xdsprobe -f C:\CCStudio_v3.3\cc\bin\brddat\ccBrd0.dat -i -v
-----[Print the controller-open software log-file]---------------------------
This utility has selected an XDS510 class product.
This utility will load the adapter 'XDS510VER3.dll'.
This utility will operate on port address '0x0240'.
TDS510USB Emulator found (USB 2.0 port)
The controller does not use a programmable FPGA.
The emulator adapter is named 'XDS510VER3.dll'.
The emulator adapter is titled 'Custom block-mode adapter for use with an TDS510
'.
The emulator adapter is version '33.0.0.0'.
The emulator adapter is using 'Block-Mode'.
The controller has a version number of '1' (0x0001).
The controller has an insertion length of '16' (0x0010).
The local memory has a base address of '0' (0x000000).
The local memory has a word capacity of '262144' (0x040000).
-----[Perform the standard path-length test on the JTAG IR and DR]-----------
This path-length test uses blocks of 512 32-bit words.
The test for the JTAG IR instruction path-length failed.
The many-ones then many-zeros tested length was -13725 bits.
The many-zeros then many-ones tested length was 54 bits.
The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 2 bits.
-----[Perform the Integrity scan-test on the JTAG IR]------------------------
This test will use blocks of 512 32-bit words.
This test will be applied just once.
Do a test using 0xFFFFFFFF.
Test 1 Word 0: scanned out 0xFFFFFFFF and scanned in 0xFFC14340.
Scan tests: 1, skipped: 0, failed: 1
Do a test using 0x00000000.
Test 2 Word 0: scanned out 0x00000000 and scanned in 0x003FFFFF.
Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 82: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 83: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 84: scanned out 0x00000000 and scanned in 0x0000FFFF.
Scan tests: 2, skipped: 0, failed: 2
Do a test using 0xFE03E0E2.
Test 3 Word 0: scanned out 0xFE03E0E2 and scanned in 0x38800000.
Test 3 Word 1: scanned out 0xFE03E0E2 and scanned in 0x38BF80F8.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 3, skipped: 0, failed: 3
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 4
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 5
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 6
Some of the values were corrupted - 66.7 percent.
The JTAG IR Integrity scan-test has failed.
-----[Perform the Integrity scan-test on the JTAG DR]------------------------
This test will use blocks of 512 32-bit words.
This test will be applied just once.
Do a test using 0xFFFFFFFF.
Test 1 Word 79: scanned out 0xFFFFFFFF and scanned in 0x3FFFFFFF.
Test 1 Word 80: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
Test 1 Word 81: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
Test 1 Word 82: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
Test 1 Word 83: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
Test 1 Word 84: scanned out 0xFFFFFFFF and scanned in 0xFFFFECC3.
Scan tests: 1, skipped: 0, failed: 1
Do a test using 0x00000000.
Test 2 Word 80: scanned out 0x00000000 and scanned in 0xC0000000.
Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 2, skipped: 0, failed: 2
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 3
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 4
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 5
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 6
Some of the values were corrupted - 1.5 percent.
The JTAG DR Integrity scan-test has failed.
Best regards
Peter
>Hello Peter,
>
>On Tue, May 27, 2008 at 11:53 PM, wrote:
>> Hi
>>
>> This might be a dumb question.
>> What is the output waveform of the TDI pin on the Jtag which is >connected to
>> the target board? Sine wave or square wave?
>
>Just to be clear - TDI [as in Test Data Input] on pin 3 of the 14 pin
>header comes from the Emulator and is an input to the target.
>This is a digital signal that goes from ground to about 3v. If you
>look at it in relation to TCLK_RET [pin 9 - JTAG clock] you should be
>able to determine if the signal is okay. You can use the '-g
>0x55555555 -c' option in xdsprobe to generate a continuous pattern of
>alternating bits.
>Both signals should be 'clean square waves'.
>
>The same holds true for TDO [as in Test Data Output from the target to
>the emulator] on pin 7 with one major exception - when TDO quits
>sending valid data [like between words] it "tristates" [or goes Hi-Z].
> When this occurs, you will see what looks like a "capacitor discharge
>ramp" [if the last bit was a '1'] or a small "capacitor charge ramp"
>[if the last bit was '0']. This can extend over multiple clocks.
>
>mikedunn
>>
>> Best regards
>> Peter
I just read one of your artical about xdsprobe this morning, which is very helpful. I also found a TI document to get more details.
With your help, I am one step close to the truth. When I do the xdsprobe test, the system passes some basic tests. But, when it goes to the path-length test, the system starts to fail. The following is the test result. Could you please have a quick look. Do you know what might be going wrong? I am doing the 0x55555555 test right now. I can see the signal from TDI, which is not so consistent with the defined value. Still modifying the ccBrd0.dat file to get the correct result.
I have got the latest driver from wintech with the C672X support, which doesn't makes any difference.
\bin\xdsprobe -f C:\CCStudio_v3.3\cc\bin\brddat\ccBrd0.dat -i -v
-----[Print the controller-open software log-file]---------------------------
This utility has selected an XDS510 class product.
This utility will load the adapter 'XDS510VER3.dll'.
This utility will operate on port address '0x0240'.
TDS510USB Emulator found (USB 2.0 port)
The controller does not use a programmable FPGA.
The emulator adapter is named 'XDS510VER3.dll'.
The emulator adapter is titled 'Custom block-mode adapter for use with an TDS510
'.
The emulator adapter is version '33.0.0.0'.
The emulator adapter is using 'Block-Mode'.
The controller has a version number of '1' (0x0001).
The controller has an insertion length of '16' (0x0010).
The local memory has a base address of '0' (0x000000).
The local memory has a word capacity of '262144' (0x040000).
-----[Perform the standard path-length test on the JTAG IR and DR]-----------
This path-length test uses blocks of 512 32-bit words.
The test for the JTAG IR instruction path-length failed.
The many-ones then many-zeros tested length was -13725 bits.
The many-zeros then many-ones tested length was 54 bits.
The test for the JTAG DR bypass path-length succeeded.
The JTAG DR bypass path-length is 2 bits.
-----[Perform the Integrity scan-test on the JTAG IR]------------------------
This test will use blocks of 512 32-bit words.
This test will be applied just once.
Do a test using 0xFFFFFFFF.
Test 1 Word 0: scanned out 0xFFFFFFFF and scanned in 0xFFC14340.
Scan tests: 1, skipped: 0, failed: 1
Do a test using 0x00000000.
Test 2 Word 0: scanned out 0x00000000 and scanned in 0x003FFFFF.
Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 82: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 83: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
Test 2 Word 84: scanned out 0x00000000 and scanned in 0x0000FFFF.
Scan tests: 2, skipped: 0, failed: 2
Do a test using 0xFE03E0E2.
Test 3 Word 0: scanned out 0xFE03E0E2 and scanned in 0x38800000.
Test 3 Word 1: scanned out 0xFE03E0E2 and scanned in 0x38BF80F8.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 3, skipped: 0, failed: 3
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 4
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 5
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 6
Some of the values were corrupted - 66.7 percent.
The JTAG IR Integrity scan-test has failed.
-----[Perform the Integrity scan-test on the JTAG DR]------------------------
This test will use blocks of 512 32-bit words.
This test will be applied just once.
Do a test using 0xFFFFFFFF.
Test 1 Word 79: scanned out 0xFFFFFFFF and scanned in 0x3FFFFFFF.
Test 1 Word 80: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
Test 1 Word 81: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
Test 1 Word 82: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
Test 1 Word 83: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
Test 1 Word 84: scanned out 0xFFFFFFFF and scanned in 0xFFFFECC3.
Scan tests: 1, skipped: 0, failed: 1
Do a test using 0x00000000.
Test 2 Word 80: scanned out 0x00000000 and scanned in 0xC0000000.
Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
The details of the first eight errors have been provided.
The utility will now report only the count of failed tests.
Scan tests: 2, skipped: 0, failed: 2
Do a test using 0xFE03E0E2.
Scan tests: 3, skipped: 0, failed: 3
Do a test using 0x01FC1F1D.
Scan tests: 4, skipped: 0, failed: 4
Do a test using 0x5533CCAA.
Scan tests: 5, skipped: 0, failed: 5
Do a test using 0xAACC3355.
Scan tests: 6, skipped: 0, failed: 6
Some of the values were corrupted - 1.5 percent.
The JTAG DR Integrity scan-test has failed.
Best regards
Peter
>Hello Peter,
>
>On Tue, May 27, 2008 at 11:53 PM, wrote:
>> Hi
>>
>> This might be a dumb question.
>> What is the output waveform of the TDI pin on the Jtag which is >connected to
>> the target board? Sine wave or square wave?
>
>Just to be clear - TDI [as in Test Data Input] on pin 3 of the 14 pin
>header comes from the Emulator and is an input to the target.
>This is a digital signal that goes from ground to about 3v. If you
>look at it in relation to TCLK_RET [pin 9 - JTAG clock] you should be
>able to determine if the signal is okay. You can use the '-g
>0x55555555 -c' option in xdsprobe to generate a continuous pattern of
>alternating bits.
>Both signals should be 'clean square waves'.
>
>The same holds true for TDO [as in Test Data Output from the target to
>the emulator] on pin 7 with one major exception - when TDO quits
>sending valid data [like between words] it "tristates" [or goes Hi-Z].
> When this occurs, you will see what looks like a "capacitor discharge
>ramp" [if the last bit was a '1'] or a small "capacitor charge ramp"
>[if the last bit was '0']. This can extend over multiple clocks.
>
>mikedunn
>>
>> Best regards
>> Peter
Reply by ●May 28, 20082008-05-28
Peter,
My comments below are marked .
mikedunn
On Wed, May 28, 2008 at 4:43 AM, wrote:
> Hi Mike
>
> I just read one of your artical about xdsprobe this morning, which is very
> helpful. I also found a TI document to get more details.
> With your help, I am one step close to the truth. When I do the xdsprobe
> test, the system passes some basic tests. But, when it goes to the
> path-length test, the system starts to fail. The following is the test
> result. Could you please have a quick look. Do you know what might be going
> wrong? I am doing the 0x55555555 test right now. I can see the signal from
> TDI, which is not so consistent with the defined value. Still modifying the
> ccBrd0.dat file to get the correct result.
>
> I have got the latest driver from wintech with the C672X support, which
> doesn't makes any difference.
>
> \bin\xdsprobe -f C:\CCStudio_v3.3\cc\bin\brddat\ccBrd0.dat -i -v
>
> -----[Print the controller-open software
> log-file]---------------------------
>
> This utility has selected an XDS510 class product.
> This utility will load the adapter 'XDS510VER3.dll'.
> This utility will operate on port address '0x0240'.
> TDS510USB Emulator found (USB 2.0 port)
> The controller does not use a programmable FPGA.
> The emulator adapter is named 'XDS510VER3.dll'.
> The emulator adapter is titled 'Custom block-mode adapter for use with an
> TDS510
> '.
> The emulator adapter is version '33.0.0.0'.
> The emulator adapter is using 'Block-Mode'.
> The controller has a version number of '1' (0x0001).
> The controller has an insertion length of '16' (0x0010).
> The local memory has a base address of '0' (0x000000).
> The local memory has a word capacity of '262144' (0x040000).
>
> -----[Perform the standard path-length test on the JTAG IR and
> DR]-----------
>
> This path-length test uses blocks of 512 32-bit words.
>
> The test for the JTAG IR instruction path-length failed.
> The many-ones then many-zeros tested length was -13725 bits.
> The many-zeros then many-ones tested length was 54 bits.
>
Very interesting. The 'zeroes' test failed, but the 'ones' test
passed. [IR = 46 for DSP + 8 for bypass = 54]
The first thing that comes to mind is a TDI/TDO signal integrity
problem wrt driving the signal to ground.
What is the freq. of TCLK??
> The test for the JTAG DR bypass path-length succeeded.
> The JTAG DR bypass path-length is 2 bits.
>
> -----[Perform the Integrity scan-test on the JTAG
> IR]------------------------
>
> This test will use blocks of 512 32-bit words.
> This test will be applied just once.
>
> Do a test using 0xFFFFFFFF.
> Test 1 Word 0: scanned out 0xFFFFFFFF and scanned in 0xFFC14340.
It looks like about 22 bits were 'left over from last time' [0xC14340]
> Scan tests: 1, skipped: 0, failed: 1
> Do a test using 0x00000000.
> Test 2 Word 0: scanned out 0x00000000 and scanned in 0x003FFFFF.
It looks like 22 bits were 'left over from last test' [0x3FFFFF]
> Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 82: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 83: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 84: scanned out 0x00000000 and scanned in 0x0000FFFF.
The previous '22 bit issues' could arguably be software or
hardware. This set of errors [81-84] are most certainly software.
The emulator has scanned out 2592 bits [ words 0-80 words x 32
bits] and then mysteriously picks up 112 bits from the previous test
and then finishes successfully. This feat, IMO, is being accomplished
by software.
> Scan tests: 2, skipped: 0, failed: 2
> Do a test using 0xFE03E0E2.
> Test 3 Word 0: scanned out 0xFE03E0E2 and scanned in 0x38800000.
> Test 3 Word 1: scanned out 0xFE03E0E2 and scanned in 0x38BF80F8.
> The details of the first eight errors have been provided.
> The utility will now report only the count of failed tests.
> Scan tests: 3, skipped: 0, failed: 3
> Do a test using 0x01FC1F1D.
> Scan tests: 4, skipped: 0, failed: 4
> Do a test using 0x5533CCAA.
> Scan tests: 5, skipped: 0, failed: 5
> Do a test using 0xAACC3355.
> Scan tests: 6, skipped: 0, failed: 6
> Some of the values were corrupted - 66.7 percent.
>
> The JTAG IR Integrity scan-test has failed.
>
> -----[Perform the Integrity scan-test on the JTAG
> DR]------------------------
>
> This test will use blocks of 512 32-bit words.
> This test will be applied just once.
>
> Do a test using 0xFFFFFFFF.
> Test 1 Word 79: scanned out 0xFFFFFFFF and scanned in 0x3FFFFFFF.
> Test 1 Word 80: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
We again see data left over from a previous test.
Peter,
I think that you should contact WinTech and request a 'NON-block mode
DLL' for troubleshooting. Or if they have a way to turn off 'block
mode'.
NOTE:
Running in 'nonblock mode' is *V_E_R_Y S_L_O_W*. But it could be a
valuable troubleshooting tool.
mikedunn
> Test 1 Word 81: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
> Test 1 Word 82: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
> Test 1 Word 83: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
> Test 1 Word 84: scanned out 0xFFFFFFFF and scanned in 0xFFFFECC3.
> Scan tests: 1, skipped: 0, failed: 1
> Do a test using 0x00000000.
> Test 2 Word 80: scanned out 0x00000000 and scanned in 0xC0000000.
> Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> The details of the first eight errors have been provided.
> The utility will now report only the count of failed tests.
> Scan tests: 2, skipped: 0, failed: 2
> Do a test using 0xFE03E0E2.
> Scan tests: 3, skipped: 0, failed: 3
> Do a test using 0x01FC1F1D.
> Scan tests: 4, skipped: 0, failed: 4
> Do a test using 0x5533CCAA.
> Scan tests: 5, skipped: 0, failed: 5
> Do a test using 0xAACC3355.
> Scan tests: 6, skipped: 0, failed: 6
> Some of the values were corrupted - 1.5 percent.
>
> The JTAG DR Integrity scan-test has failed.
>
> Best regards
> Peter
>
>>Hello Peter,
>
>>
>>On Tue, May 27, 2008 at 11:53 PM, wrote:
>>> Hi
>>>
>>> This might be a dumb question.
>>> What is the output waveform of the TDI pin on the Jtag which is
>>> >connected to
>>> the target board? Sine wave or square wave?
>>
>>Just to be clear - TDI [as in Test Data Input] on pin 3 of the 14 pin
>>header comes from the Emulator and is an input to the target.
>>This is a digital signal that goes from ground to about 3v. If you
>>look at it in relation to TCLK_RET [pin 9 - JTAG clock] you should be
>>able to determine if the signal is okay. You can use the '-g
>>0x55555555 -c' option in xdsprobe to generate a continuous pattern of
>>alternating bits.
>>Both signals should be 'clean square waves'.
>>
>>The same holds true for TDO [as in Test Data Output from the target to
>>the emulator] on pin 7 with one major exception - when TDO quits
>>sending valid data [like between words] it "tristates" [or goes Hi-Z].
>> When this occurs, you will see what looks like a "capacitor discharge
>>ramp" [if the last bit was a '1'] or a small "capacitor charge ramp"
>>[if the last bit was '0']. This can extend over multiple clocks.
>>
>>mikedunn
>>>
>>> Best regards
>>> Peter
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
My comments below are marked .
mikedunn
On Wed, May 28, 2008 at 4:43 AM, wrote:
> Hi Mike
>
> I just read one of your artical about xdsprobe this morning, which is very
> helpful. I also found a TI document to get more details.
> With your help, I am one step close to the truth. When I do the xdsprobe
> test, the system passes some basic tests. But, when it goes to the
> path-length test, the system starts to fail. The following is the test
> result. Could you please have a quick look. Do you know what might be going
> wrong? I am doing the 0x55555555 test right now. I can see the signal from
> TDI, which is not so consistent with the defined value. Still modifying the
> ccBrd0.dat file to get the correct result.
>
> I have got the latest driver from wintech with the C672X support, which
> doesn't makes any difference.
>
> \bin\xdsprobe -f C:\CCStudio_v3.3\cc\bin\brddat\ccBrd0.dat -i -v
>
> -----[Print the controller-open software
> log-file]---------------------------
>
> This utility has selected an XDS510 class product.
> This utility will load the adapter 'XDS510VER3.dll'.
> This utility will operate on port address '0x0240'.
> TDS510USB Emulator found (USB 2.0 port)
> The controller does not use a programmable FPGA.
> The emulator adapter is named 'XDS510VER3.dll'.
> The emulator adapter is titled 'Custom block-mode adapter for use with an
> TDS510
> '.
> The emulator adapter is version '33.0.0.0'.
> The emulator adapter is using 'Block-Mode'.
> The controller has a version number of '1' (0x0001).
> The controller has an insertion length of '16' (0x0010).
> The local memory has a base address of '0' (0x000000).
> The local memory has a word capacity of '262144' (0x040000).
>
> -----[Perform the standard path-length test on the JTAG IR and
> DR]-----------
>
> This path-length test uses blocks of 512 32-bit words.
>
> The test for the JTAG IR instruction path-length failed.
> The many-ones then many-zeros tested length was -13725 bits.
> The many-zeros then many-ones tested length was 54 bits.
>
Very interesting. The 'zeroes' test failed, but the 'ones' test
passed. [IR = 46 for DSP + 8 for bypass = 54]
The first thing that comes to mind is a TDI/TDO signal integrity
problem wrt driving the signal to ground.
What is the freq. of TCLK??
> The test for the JTAG DR bypass path-length succeeded.
> The JTAG DR bypass path-length is 2 bits.
>
> -----[Perform the Integrity scan-test on the JTAG
> IR]------------------------
>
> This test will use blocks of 512 32-bit words.
> This test will be applied just once.
>
> Do a test using 0xFFFFFFFF.
> Test 1 Word 0: scanned out 0xFFFFFFFF and scanned in 0xFFC14340.
It looks like about 22 bits were 'left over from last time' [0xC14340]
> Scan tests: 1, skipped: 0, failed: 1
> Do a test using 0x00000000.
> Test 2 Word 0: scanned out 0x00000000 and scanned in 0x003FFFFF.
It looks like 22 bits were 'left over from last test' [0x3FFFFF]
> Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 82: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 83: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 84: scanned out 0x00000000 and scanned in 0x0000FFFF.
The previous '22 bit issues' could arguably be software or
hardware. This set of errors [81-84] are most certainly software.
The emulator has scanned out 2592 bits [ words 0-80 words x 32
bits] and then mysteriously picks up 112 bits from the previous test
and then finishes successfully. This feat, IMO, is being accomplished
by software.
> Scan tests: 2, skipped: 0, failed: 2
> Do a test using 0xFE03E0E2.
> Test 3 Word 0: scanned out 0xFE03E0E2 and scanned in 0x38800000.
> Test 3 Word 1: scanned out 0xFE03E0E2 and scanned in 0x38BF80F8.
> The details of the first eight errors have been provided.
> The utility will now report only the count of failed tests.
> Scan tests: 3, skipped: 0, failed: 3
> Do a test using 0x01FC1F1D.
> Scan tests: 4, skipped: 0, failed: 4
> Do a test using 0x5533CCAA.
> Scan tests: 5, skipped: 0, failed: 5
> Do a test using 0xAACC3355.
> Scan tests: 6, skipped: 0, failed: 6
> Some of the values were corrupted - 66.7 percent.
>
> The JTAG IR Integrity scan-test has failed.
>
> -----[Perform the Integrity scan-test on the JTAG
> DR]------------------------
>
> This test will use blocks of 512 32-bit words.
> This test will be applied just once.
>
> Do a test using 0xFFFFFFFF.
> Test 1 Word 79: scanned out 0xFFFFFFFF and scanned in 0x3FFFFFFF.
> Test 1 Word 80: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
We again see data left over from a previous test.
Peter,
I think that you should contact WinTech and request a 'NON-block mode
DLL' for troubleshooting. Or if they have a way to turn off 'block
mode'.
NOTE:
Running in 'nonblock mode' is *V_E_R_Y S_L_O_W*. But it could be a
valuable troubleshooting tool.
mikedunn
> Test 1 Word 81: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
> Test 1 Word 82: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
> Test 1 Word 83: scanned out 0xFFFFFFFF and scanned in 0x355AACC3.
> Test 1 Word 84: scanned out 0xFFFFFFFF and scanned in 0xFFFFECC3.
> Scan tests: 1, skipped: 0, failed: 1
> Do a test using 0x00000000.
> Test 2 Word 80: scanned out 0x00000000 and scanned in 0xC0000000.
> Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> The details of the first eight errors have been provided.
> The utility will now report only the count of failed tests.
> Scan tests: 2, skipped: 0, failed: 2
> Do a test using 0xFE03E0E2.
> Scan tests: 3, skipped: 0, failed: 3
> Do a test using 0x01FC1F1D.
> Scan tests: 4, skipped: 0, failed: 4
> Do a test using 0x5533CCAA.
> Scan tests: 5, skipped: 0, failed: 5
> Do a test using 0xAACC3355.
> Scan tests: 6, skipped: 0, failed: 6
> Some of the values were corrupted - 1.5 percent.
>
> The JTAG DR Integrity scan-test has failed.
>
> Best regards
> Peter
>
>>Hello Peter,
>
>>
>>On Tue, May 27, 2008 at 11:53 PM, wrote:
>>> Hi
>>>
>>> This might be a dumb question.
>>> What is the output waveform of the TDI pin on the Jtag which is
>>> >connected to
>>> the target board? Sine wave or square wave?
>>
>>Just to be clear - TDI [as in Test Data Input] on pin 3 of the 14 pin
>>header comes from the Emulator and is an input to the target.
>>This is a digital signal that goes from ground to about 3v. If you
>>look at it in relation to TCLK_RET [pin 9 - JTAG clock] you should be
>>able to determine if the signal is okay. You can use the '-g
>>0x55555555 -c' option in xdsprobe to generate a continuous pattern of
>>alternating bits.
>>Both signals should be 'clean square waves'.
>>
>>The same holds true for TDO [as in Test Data Output from the target to
>>the emulator] on pin 7 with one major exception - when TDO quits
>>sending valid data [like between words] it "tristates" [or goes Hi-Z].
>> When this occurs, you will see what looks like a "capacitor discharge
>>ramp" [if the last bit was a '1'] or a small "capacitor charge ramp"
>>[if the last bit was '0']. This can extend over multiple clocks.
>>
>>mikedunn
>>>
>>> Best regards
>>> Peter
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●May 29, 20082008-05-29
Hi Mike
Thank you so much for your reply.
The TCLK freq. is 11.5MHz.
I am really new on debuging Jtag. So I make some assumption from what I have seem. So please correct me if I am mistaken.
-All the Jtag pins (14 pin version) go to and stay at logic high ,when the target powers on and connects to the emulator, except the TCLK and GND pins of course.
-The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO pin. If the input and return are matched. The test passed.
-The emulator sends out 32-bits word which is a combination of two 16-bits words with few cycles gap in between.
-When I do the 0x55555555 test, I should see a 32-bits word with a few cycle gapes in between (5555--5555) been continually sent out from TDI (with larger gape between each 32-bits). I should see the same signal return from the TDO.
I assume the above situations are correct. From these assumption, I found that the TDI and TDO are different when I observe the wave form from the oscilloscope. I have varied the TDI input, but still get different result.
Do you think most of my issue comes from the emulator or the target hardware? Coz I am prepare to replace my emulator if it causes so many troubles, but I have to make sure which parts go wrong. Of course that's my duty to verify that, but I am looking for some suggestions from experienced engineer.
Best regards
Peter
Thank you so much for your reply.
The TCLK freq. is 11.5MHz.
I am really new on debuging Jtag. So I make some assumption from what I have seem. So please correct me if I am mistaken.
-All the Jtag pins (14 pin version) go to and stay at logic high ,when the target powers on and connects to the emulator, except the TCLK and GND pins of course.
-The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO pin. If the input and return are matched. The test passed.
-The emulator sends out 32-bits word which is a combination of two 16-bits words with few cycles gap in between.
-When I do the 0x55555555 test, I should see a 32-bits word with a few cycle gapes in between (5555--5555) been continually sent out from TDI (with larger gape between each 32-bits). I should see the same signal return from the TDO.
I assume the above situations are correct. From these assumption, I found that the TDI and TDO are different when I observe the wave form from the oscilloscope. I have varied the TDI input, but still get different result.
Do you think most of my issue comes from the emulator or the target hardware? Coz I am prepare to replace my emulator if it causes so many troubles, but I have to make sure which parts go wrong. Of course that's my duty to verify that, but I am looking for some suggestions from experienced engineer.
Best regards
Peter
Reply by ●May 29, 20082008-05-29
Peter,
On Thu, May 29, 2008 at 3:09 AM, wrote:
> Hi Mike
>
> Thank you so much for your reply.
> The TCLK freq. is 11.5MHz.
> I am really new on debuging Jtag. So I make some assumption from what I have
> seem. So please correct me if I am mistaken.
>
> -All the Jtag pins (14 pin version) go to and stay at logic high ,when the
> target powers on and connects to the emulator, except the TCLK and GND pins
> of course.
>
> -The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g
> 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO
> pin. If the input and return are matched. The test passed.
>
> -The emulator sends out 32-bits word which is a combination of two 16-bits
> words with few cycles gap in between.
>
> -When I do the 0x55555555 test, I should see a 32-bits word with a few cycle
> gapes in between (5555--5555) been continually sent out from TDI (with
> larger gape between each 32-bits). I should see the same signal return from
> the TDO.
Very good on the details with one small exception - Remember the IR
length?? [54 bits on c6727] The IR is a 54 bit shift register with TDI
as the input and TDO is the output. This will cause a 54 clock delay
between TDI and TDO - a bit difficult to see anything useful with a
scope.
When you use 'xdsprobe -f brddat\ccBrd0.dat -v -g 0x55555555 -c' and
you hit a key, the test will switch from testing the IR shift register
to the DR shift register [2 bit delay- much easier to see on the
scope].
>
> I assume the above situations are correct. From these assumption, I found
> that the TDI and TDO are different when I observe the wave form from the
> oscilloscope. I have varied the TDI input, but still get different result.
>
> Do you think most of my issue comes from the emulator or the target
> hardware?
>From yesterday...
-----------------------------
It looks like about 22 bits were 'left over from last time' [0xC14340]
> Scan tests: 1, skipped: 0, failed: 1
> Do a test using 0x00000000.
> Test 2 Word 0: scanned out 0x00000000 and scanned in 0x003FFFFF.
It looks like 22 bits were 'left over from last test' [0x3FFFFF]
> Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 82: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 83: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 84: scanned out 0x00000000 and scanned in 0x0000FFFF.
The previous '22 bit issues' could arguably be software or
hardware. This set of errors [81-84] are most certainly software.
The emulator has scanned out 2592 bits [ words 0-80 words x 32
bits] and then mysteriously picks up 112 bits from the previous test
and then finishes successfully. This feat, IMO, is being accomplished
by software
-----------------
1. I assure you that the above error is not caused by target hardware.
2. The error indicates a software problem.
3. The type of errors indicate that the target is 'basically OK wrt
JTAG interface'. It is difficult to say anything beyond that until
the main problem is solved.
4. I believe that the primary problem is in the Wintech
'WTUSB5102.dll' while performinf 'block mode writes'.
5. There may be a secondary problem with signal integrity [TCLK_RET,
TDI, TDO, TMS].
6. If the "seller of the emulator" will not support it [or give credit
toward a replacement], you might look at buying from someone else.
mikedunn
> Coz I am prepare to replace my emulator if it causes so many
> troubles, but I have to make sure which parts go wrong. Of course that's my
> duty to verify that, but I am looking for some suggestions from experienced
> engineer.
>
> Best regards
> Peter
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Thu, May 29, 2008 at 3:09 AM, wrote:
> Hi Mike
>
> Thank you so much for your reply.
> The TCLK freq. is 11.5MHz.
> I am really new on debuging Jtag. So I make some assumption from what I have
> seem. So please correct me if I am mistaken.
>
> -All the Jtag pins (14 pin version) go to and stay at logic high ,when the
> target powers on and connects to the emulator, except the TCLK and GND pins
> of course.
>
> -The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g
> 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO
> pin. If the input and return are matched. The test passed.
>
> -The emulator sends out 32-bits word which is a combination of two 16-bits
> words with few cycles gap in between.
>
> -When I do the 0x55555555 test, I should see a 32-bits word with a few cycle
> gapes in between (5555--5555) been continually sent out from TDI (with
> larger gape between each 32-bits). I should see the same signal return from
> the TDO.
Very good on the details with one small exception - Remember the IR
length?? [54 bits on c6727] The IR is a 54 bit shift register with TDI
as the input and TDO is the output. This will cause a 54 clock delay
between TDI and TDO - a bit difficult to see anything useful with a
scope.
When you use 'xdsprobe -f brddat\ccBrd0.dat -v -g 0x55555555 -c' and
you hit a key, the test will switch from testing the IR shift register
to the DR shift register [2 bit delay- much easier to see on the
scope].
>
> I assume the above situations are correct. From these assumption, I found
> that the TDI and TDO are different when I observe the wave form from the
> oscilloscope. I have varied the TDI input, but still get different result.
>
> Do you think most of my issue comes from the emulator or the target
> hardware?
>From yesterday...
-----------------------------
It looks like about 22 bits were 'left over from last time' [0xC14340]
> Scan tests: 1, skipped: 0, failed: 1
> Do a test using 0x00000000.
> Test 2 Word 0: scanned out 0x00000000 and scanned in 0x003FFFFF.
It looks like 22 bits were 'left over from last test' [0x3FFFFF]
> Test 2 Word 81: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 82: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 83: scanned out 0x00000000 and scanned in 0xFFFFFFFF.
> Test 2 Word 84: scanned out 0x00000000 and scanned in 0x0000FFFF.
The previous '22 bit issues' could arguably be software or
hardware. This set of errors [81-84] are most certainly software.
The emulator has scanned out 2592 bits [ words 0-80 words x 32
bits] and then mysteriously picks up 112 bits from the previous test
and then finishes successfully. This feat, IMO, is being accomplished
by software
-----------------
1. I assure you that the above error is not caused by target hardware.
2. The error indicates a software problem.
3. The type of errors indicate that the target is 'basically OK wrt
JTAG interface'. It is difficult to say anything beyond that until
the main problem is solved.
4. I believe that the primary problem is in the Wintech
'WTUSB5102.dll' while performinf 'block mode writes'.
5. There may be a secondary problem with signal integrity [TCLK_RET,
TDI, TDO, TMS].
6. If the "seller of the emulator" will not support it [or give credit
toward a replacement], you might look at buying from someone else.
mikedunn
> Coz I am prepare to replace my emulator if it causes so many
> troubles, but I have to make sure which parts go wrong. Of course that's my
> duty to verify that, but I am looking for some suggestions from experienced
> engineer.
>
> Best regards
> Peter
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●June 3, 20082008-06-03
Hello Peter,
Have you resolved your emulator problem??
Are there any new developments??
mikedunn
On 5/29/08, i...@gmail.com wrote:
>
> Hi Mike
>
> Thank you so much for your reply.
> The TCLK freq. is 11.5MHz.
> I am really new on debuging Jtag. So I make some assumption from what I
> have seem. So please correct me if I am mistaken.
>
> -All the Jtag pins (14 pin version) go to and stay at logic high ,when the
> target powers on and connects to the emulator, except the TCLK and GND pins
> of course.
>
> -The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g
> 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO
> pin. If the input and return are matched. The test passed.
>
> -The emulator sends out 32-bits word which is a combination of two 16-bits
> words with few cycles gap in between.
>
> -When I do the 0x55555555 test, I should see a 32-bits word with a few
> cycle gapes in between (5555--5555) been continually sent out from TDI (with
> larger gape between each 32-bits). I should see the same signal return from
> the TDO.
>
> I assume the above situations are correct. From these assumption, I found
> that the TDI and TDO are different when I observe the wave form from the
> oscilloscope. I have varied the TDI input, but still get different result.
>
> Do you think most of my issue comes from the emulator or the target
> hardware? Coz I am prepare to replace my emulator if it causes so many
> troubles, but I have to make sure which parts go wrong. Of course that's my
> duty to verify that, but I am looking for some suggestions from experienced
> engineer.
>
> Best regards
> Peter
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Have you resolved your emulator problem??
Are there any new developments??
mikedunn
On 5/29/08, i...@gmail.com wrote:
>
> Hi Mike
>
> Thank you so much for your reply.
> The TCLK freq. is 11.5MHz.
> I am really new on debuging Jtag. So I make some assumption from what I
> have seem. So please correct me if I am mistaken.
>
> -All the Jtag pins (14 pin version) go to and stay at logic high ,when the
> target powers on and connects to the emulator, except the TCLK and GND pins
> of course.
>
> -The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g
> 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO
> pin. If the input and return are matched. The test passed.
>
> -The emulator sends out 32-bits word which is a combination of two 16-bits
> words with few cycles gap in between.
>
> -When I do the 0x55555555 test, I should see a 32-bits word with a few
> cycle gapes in between (5555--5555) been continually sent out from TDI (with
> larger gape between each 32-bits). I should see the same signal return from
> the TDO.
>
> I assume the above situations are correct. From these assumption, I found
> that the TDI and TDO are different when I observe the wave form from the
> oscilloscope. I have varied the TDI input, but still get different result.
>
> Do you think most of my issue comes from the emulator or the target
> hardware? Coz I am prepare to replace my emulator if it causes so many
> troubles, but I have to make sure which parts go wrong. Of course that's my
> duty to verify that, but I am looking for some suggestions from experienced
> engineer.
>
> Best regards
> Peter
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●June 3, 20082008-06-03
Hi Mike
Thanks for your concern.
I just solved my problem.
Just right before I order the super expensive TI emulator. The Wintech contacts me. They give me a new driver, which strangely is from BLACKHAWK, and then magically the code can be loaded into the C672X chip without any problem.
I really appreciate all the helps from you and everyone who has ever leave me any tip. Thanks you so much.
Best regards
Peter
>Hello Peter,
>
>Have you resolved your emulator problem??
>
>Are there any new developments??
>
>mikedunn
>On 5/29/08, i...@gmail.com wrote:
>>
>> Hi Mike
>>
>> Thank you so much for your reply.
>> The TCLK freq. is 11.5MHz.
>> I am really new on debuging Jtag. So I make some assumption from what I
>> have seem. So please correct me if I am mistaken.
>>
>> -All the Jtag pins (14 pin version) go to and stay at logic high ,when the
>> target powers on and connects to the emulator, except the TCLK and GND pins
>> of course.
>>
>> -The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g
>> 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO
>> pin. If the input and return are matched. The test passed.
>>
>> -The emulator sends out 32-bits word which is a combination of two 16-bits
>> words with few cycles gap in between.
>>
>> -When I do the 0x55555555 test, I should see a 32-bits word with a few
>> cycle gapes in between (5555--5555) been continually sent out from TDI (with
>> larger gape between each 32-bits). I should see the same signal return from
>> the TDO.
>>
>> I assume the above situations are correct. From these assumption, I found
>> that the TDI and TDO are different when I observe the wave form from the
>> oscilloscope. I have varied the TDI input, but still get different result.
>>
>> Do you think most of my issue comes from the emulator or the target
>> hardware? Coz I am prepare to replace my emulator if it causes so many
>> troubles, but I have to make sure which parts go wrong. Of course that's my
>> duty to verify that, but I am looking for some suggestions from experienced
>> engineer.
>>
>> Best regards
>> Peter
Thanks for your concern.
I just solved my problem.
Just right before I order the super expensive TI emulator. The Wintech contacts me. They give me a new driver, which strangely is from BLACKHAWK, and then magically the code can be loaded into the C672X chip without any problem.
I really appreciate all the helps from you and everyone who has ever leave me any tip. Thanks you so much.
Best regards
Peter
>Hello Peter,
>
>Have you resolved your emulator problem??
>
>Are there any new developments??
>
>mikedunn
>On 5/29/08, i...@gmail.com wrote:
>>
>> Hi Mike
>>
>> Thank you so much for your reply.
>> The TCLK freq. is 11.5MHz.
>> I am really new on debuging Jtag. So I make some assumption from what I
>> have seem. So please correct me if I am mistaken.
>>
>> -All the Jtag pins (14 pin version) go to and stay at logic high ,when the
>> target powers on and connects to the emulator, except the TCLK and GND pins
>> of course.
>>
>> -The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g
>> 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO
>> pin. If the input and return are matched. The test passed.
>>
>> -The emulator sends out 32-bits word which is a combination of two 16-bits
>> words with few cycles gap in between.
>>
>> -When I do the 0x55555555 test, I should see a 32-bits word with a few
>> cycle gapes in between (5555--5555) been continually sent out from TDI (with
>> larger gape between each 32-bits). I should see the same signal return from
>> the TDO.
>>
>> I assume the above situations are correct. From these assumption, I found
>> that the TDI and TDO are different when I observe the wave form from the
>> oscilloscope. I have varied the TDI input, but still get different result.
>>
>> Do you think most of my issue comes from the emulator or the target
>> hardware? Coz I am prepare to replace my emulator if it causes so many
>> troubles, but I have to make sure which parts go wrong. Of course that's my
>> duty to verify that, but I am looking for some suggestions from experienced
>> engineer.
>>
>> Best regards
>> Peter
Reply by ●June 4, 20082008-06-04
Peter-
> Thanks for your concern.
>
> I just solved my problem.
> Just right before I order the super expensive TI emulator. The Wintech
> contacts me. They give me a new driver, which strangely is from BLACKHAWK,
> and then magically the code can be loaded into the C672X chip without any
> problem.
>
> I really appreciate all the helps from you and everyone who has ever leave
> me any tip. Thanks you so much.
Wow, good work to solve that! JTAG emulator problems can be tough, no doubt. You
should not feel bad, many group members have had to fight DSP + JTAG issues over the
years.
Also thanks for the follow-up to let everyone know. When another Wintech emulator
issue comes up, then your experience is valuable.
-Jeff
>
> >Hello Peter,
> >
> >Have you resolved your emulator problem??
> >
> >Are there any new developments??
> >
> >mikedunn
> >On 5/29/08, i...@gmail.com wrote:
> >>
> >> Hi Mike
> >>
> >> Thank you so much for your reply.
> >> The TCLK freq. is 11.5MHz.
> >> I am really new on debuging Jtag. So I make some assumption from what I
> >> have seem. So please correct me if I am mistaken.
> >>
> >> -All the Jtag pins (14 pin version) go to and stay at logic high ,when the
> >> target powers on and connects to the emulator, except the TCLK and GND pins
> >> of course.
> >>
> >> -The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g
> >> 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO
> >> pin. If the input and return are matched. The test passed.
> >>
> >> -The emulator sends out 32-bits word which is a combination of two 16-bits
> >> words with few cycles gap in between.
> >>
> >> -When I do the 0x55555555 test, I should see a 32-bits word with a few
> >> cycle gapes in between (5555--5555) been continually sent out from TDI (with
> >> larger gape between each 32-bits). I should see the same signal return from
> >> the TDO.
> >>
> >> I assume the above situations are correct. From these assumption, I found
> >> that the TDI and TDO are different when I observe the wave form from the
> >> oscilloscope. I have varied the TDI input, but still get different result.
> >>
> >> Do you think most of my issue comes from the emulator or the target
> >> hardware? Coz I am prepare to replace my emulator if it causes so many
> >> troubles, but I have to make sure which parts go wrong. Of course that's my
> >> duty to verify that, but I am looking for some suggestions from experienced
> >> engineer.
> >>
> >> Best regards
> >> Peter
> Thanks for your concern.
>
> I just solved my problem.
> Just right before I order the super expensive TI emulator. The Wintech
> contacts me. They give me a new driver, which strangely is from BLACKHAWK,
> and then magically the code can be loaded into the C672X chip without any
> problem.
>
> I really appreciate all the helps from you and everyone who has ever leave
> me any tip. Thanks you so much.
Wow, good work to solve that! JTAG emulator problems can be tough, no doubt. You
should not feel bad, many group members have had to fight DSP + JTAG issues over the
years.
Also thanks for the follow-up to let everyone know. When another Wintech emulator
issue comes up, then your experience is valuable.
-Jeff
>
> >Hello Peter,
> >
> >Have you resolved your emulator problem??
> >
> >Are there any new developments??
> >
> >mikedunn
> >On 5/29/08, i...@gmail.com wrote:
> >>
> >> Hi Mike
> >>
> >> Thank you so much for your reply.
> >> The TCLK freq. is 11.5MHz.
> >> I am really new on debuging Jtag. So I make some assumption from what I
> >> have seem. So please correct me if I am mistaken.
> >>
> >> -All the Jtag pins (14 pin version) go to and stay at logic high ,when the
> >> target powers on and connects to the emulator, except the TCLK and GND pins
> >> of course.
> >>
> >> -The "xdsprobe -f brddat\ccBrd0.dat -i -v" test, sends the 32bit word (e.g
> >> 0xFFFFFFFF) from the TDI pin to the DSP and expects the same return from TDO
> >> pin. If the input and return are matched. The test passed.
> >>
> >> -The emulator sends out 32-bits word which is a combination of two 16-bits
> >> words with few cycles gap in between.
> >>
> >> -When I do the 0x55555555 test, I should see a 32-bits word with a few
> >> cycle gapes in between (5555--5555) been continually sent out from TDI (with
> >> larger gape between each 32-bits). I should see the same signal return from
> >> the TDO.
> >>
> >> I assume the above situations are correct. From these assumption, I found
> >> that the TDI and TDO are different when I observe the wave form from the
> >> oscilloscope. I have varied the TDI input, but still get different result.
> >>
> >> Do you think most of my issue comes from the emulator or the target
> >> hardware? Coz I am prepare to replace my emulator if it causes so many
> >> troubles, but I have to make sure which parts go wrong. Of course that's my
> >> duty to verify that, but I am looking for some suggestions from experienced
> >> engineer.
> >>
> >> Best regards
> >> Peter
