AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

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
>
>------------------------------------
>
>OMAP35x EVM jump-starts low-power apps
>------------------------------------
>The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start
building applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

oh no~~~ mine just the same problem like peter`s...the EMULATOR`s problume? TDS510 USB?? 

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

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

liqunchao,

On Fri, Sep 5, 2008 at 1:09 PM,  <l...@163.com> 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.

<mld> This is wrong.
>>The many-zeros then many-ones tested length was 54 bits.

<mld> This is correct.
>>
>>The test for the JTAG DR bypass path-length succeeded.
>>The JTAG DR bypass path-length is 2 bits.

<mld> This is correct.
>>
>>-----[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.
<mld> This is wrong.
One might thing that 23 1s were still 'in the shift register' from the
previous test. If this was the only error, it is theoretically
possible that it is the test software [I do not think that it is].
>>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.
<mld> These errors look like 'confused software buffers' containing
the 1s from the previous test.
I do not remember for sure, but it seems like Peter's [or someone in a
previous post] was getting failures around word 0x8?.

>>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.
<mld> This looks like a bit shift problem - if you knock off the 2
MSBs of 0xFE03E0E2, you get 0xF80F838... which starts looking like the
failure pattern.
I am thinking an emulator related problem.
>>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.

<mld> this is an emulator sw problem in XDS510VER3.dll.

mikedunn
>>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
>>
>>------------------------------------
>>
>>OMAP35x EVM jump-starts low-power apps
>>------------------------------------
>>The modular and extensible OMAP35x Evaluation Module (EVM) enables
>> developers to start building applications based on the OMAP35x architecture:
>>http://www.DSPRelated.com/omap35x
>>
>> oh no~~~ mine just the same problem like peter`s...the EMULATOR`s problume?
> TDS510 USB??

-- 
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

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

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )