Re: Re: R: Re: XDS510-USB2.0 + C6727 - Load Program problem

All-

The original link given for the "LT430" XDS510-compatible JTAG emulator (subject of
this thread) was on a website labeled Litian Co (Harbin, CHN). The website hasn't
been working for a couple of days now... does anyone know if the site has moved?

-Jeff

Michael Dunn wrote:
>
> pco73,
>
> see multiple comments in line below.
>
> mikedunn
>
> On Sun, Jun 28, 2009 at 8:51 AM, p...@libero.it wrote:
> > Hi Mike,
> >
> > OK, this is my ccBrd0.dat file:
> >
> > # config version=3.5
> > $ uscif
> > slowclk=YES
> > tdoedgeL
> > $ /
> > $ sepk
> > pod_drvr=XDS510-USB2.dll
> > pod_port=0x240
> > $ /
> > @ tms320c6720_0 family=tms320c672x
> > @ bypass_0 family=bypass irbits=8
> > # /
> >
> >
> > I have looked at your very usefull tutorials and I have done some tests:
> >
> > 1) xdsprobe -f brddat/ccBrd0.dat -r -v
> >
> > -----[Print the reset-command software log-file]
> > -----------------------------
> >
> > This utility has selected an XDS510 class product.
> > This utility will load the adapter 'XDS510-USB2.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 'XDS510-USB2.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).
> > This utility will now attempt to reset the controller.
> > This utility has successfully reset the controller.
> >
> > -----[Print the reset-command hardware log-file]
> > -----------------------------
> >
> > The scan-path will be reset by toggling the JTAG TRST signal.
> > The controller type is the production TBC (74ACT8990).
> > The controller has been hardware reset via its support logic.
> > The controller has been software reset via its support logic.
> > The software is configured to use only TBC features.
> > The software is configured for slower clock operation.
> > The controller has a logic ONE on its EMU[0] input pin.
> > The controller has a logic ONE on its EMU[1] input pin.
> > The controller will use falling-edge timing on output pins.
> > The controller may use rising edge timing on input pins.
> > The support logic has not previously detected a power-loss.
> > The scan-path link-delay has been set to exactly '0' (0x0000).
> >
> >
> > 2) xdsprobe -f 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 'XDS510-USB2.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 'XDS510-USB2.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 -13712 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.
>
> 2 bits i8s correct for the DR on a 6727.
> The IR length should always be 54 bits [46 + 8].
>
> >
> > -----[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 0xFFC14240.
> > 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.
>
> The 'XDS510-USB2.dll' is broken. There is a problem with the way the
> data buffers are managed or handled in this DLL. I do not think that
> you will ever get it to work with this DLL.
> You might try running the test multiple times to see if the results
> are the same.
>
> > 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.
>
> The wrong pattern '0x355AACC3.' is from a previous test - more
> indication that the buffers are messed up.
>
> > 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.
> >
> >
> > I hope those tests can help us ( you :-) ) to understand...
> >
> > Thanks again.
> >
> >
> >>pco73,
> >
> >>On Thu, Jun 25, 2009 at 7:16 PM, p...@libero.it wrote:
> >>> Hi Mike,
> >>>
> >>> thanks for your reply.
> >>>
> >>> Yes, I was tempted to try it because of the cheap price and it seems to
> >>> work,
> >>> because it can connect to the dsp C6727 target, I can write memory
> > directly
> >>> and load dat files.
> >>> That's why I am disappointed I am not able to load my program out file.
> >>> Do you have same ideas to try?
> >
> >>
> >>You can search the archives of this group for past problems - there
> >>have been several with various 'far east emulators' - GAOtek, SEED,
> >>and others all appear to have the same design and problems -
> >>especially with the 6727.
> >>
> >>Your problem is likely a configuration or bad "adapter DLL" from the
> >>vendor.
> >>
> >>If you post a copy of the
> >> ....\cc\bin\brddat\ccBrd0.dat file [it is a text file], I will take
> >>a look and see if I spot anything.
> >>
> >>mikedunn
> >
> >>>
> >>> Thanks.
> >>>>pco73,
> >>>>
> >>>>I have not seen this device.
> >>>>
> >>>>According to TI, this is NOT a TI product. [nor does it look like it
> >>>>is 'legit TI']
> >>>>
> >>>>It appears to be a forgery of someone's emulator stuffed in an 'off
> >>>>the shelf box' with TI markings.
> >>>>
> >>>>mikedunn
> >>>>
> >>>>On Thu, Jun 25, 2009 at 3:26 PM, wrote:
> >>>>>
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> I have a XDS510-USB2.0 TI DSP Emulator as
> >>>>> "http://www.lt430.com/ProductShow.asp?ID9" and a custom board with
> > dsp
> >>>>> C6727. I have installed CCS3.3.54.1 and I have used CCS Setup to add
> > "C672x
> >>>>> XDS510 Emulator" to my system configuration. This configuration provides
> > a
> >>>>> BYPASS_0 processor type and a TMS320C6720_0 processor type with driver
> >>>>> "tixds6000.drv". I have changed Property/Configuration File with
> >>>>> "XDS510-USB2.cfg" provided with the Emulator, saved and quit.
> >>>>>
> >>>>> I start CCS3, I can reset, I can connect to the board, I can see the
> > memory
> >>>>> and registers correctly, but when I "Load Program",loading is executed
> >>>>> without errors, all symbols are loaded but memory is unchanged.
> >>>>>
> >>>>> If I try to write a memory address directly or if I load a dat file, it
> >>>>> works, I can see the memory to change value, but if I load my program,
> >>>>> memory is not overwritten by the code of the program.
> >>>>>
> >>>>> Please, help me

_____________________________________ Start a New Thread