Paolo,
On 10/28/2011 2:48 AM, Proware (tin.it) wrote:
> Thank you Mike,
> I was waiting for the problems to be solved before posting the result
> to the group in order to avoid intermediate steps.
sometimes the journey is more interesting than the destination :-)
[at least for some people]
> Real filename is TIXDS100usb_Connection.xml, and as
you said it's the
> only XDS100 connection file. I've modified it following your
> suggestion and I've renamed the original adding ".ori" at the end.
> I'm able to connect with the target. My feeling is that it's a
little
> bit harder than before, sometimes I have to push the reset button and
> try a couple of times before succeeding (but may be it's just my
feeling).
> I'm also able to set/check memory with no apparent problem.
> Now when I try to load the .out file I have problems as soon as CCS
> tries to load .cinit, that in my case is at 0x155F8 (int.RAM). I see
> the memory address 0 (.boot_load section) going blank (0x00000000) and
> then filled with something, but the 2nd section shown on the Loading
> Program popup, that is .cinit, fails at its first address (Error: File
> Loader popup window with "Data verification failed at address 0x155F8.
> Please verify target memory and memory map").
Maybe we are finding out why TI did not support the 6713. If you want
to, you can try the test below to get a better read on what is going on.
Also, you may want to try setting the 'JTAG clock edge' to the JTAG
std
instead of TI's opposite setting.
I have included the text for an asm file below. It does not execute, but
I use it for troubleshooting 'load' problems. Just create a new
project
and add only the file below to it [you can call it something like
'test.asm']. 'Compile' the file like you would a C file -
the compiler
will figure it out. You will get 1 warning - No Entry Point Defined [or
something like that], just ignore it. If you look under project options,
you should find one that will generate a listing file [.lst]. You do not
need it, but it will show the assembly code. The memory contents will be
the same as the 8 lower bits of the address. With a deterministic
pattern, it is easier to assess what is going on. Just load the
'out'
file and look at memory beginning at 0. I do not remember - you might
have to create a linker cmd file that loads the .text into address 0.
----------------first line below----------
.global mystart
.sect ".text"
bitinc .macro
.asg 256,CNT ;size of inner loop, loop counter
.loop CNT
.byte 256-CNT ;subtract remaining loop count and store
as byte
.eval CNT - 1, CNT ; update loop count
.endloop
.endm
;code start
mystart:
.asg 4,CNT ;size of outer loop
.loop CNT
bitinc ; inner loop macro
.eval CNT - 1, CNT ; update loop count
.endloop
the_end:
;code end
----------------last line above----------
> I tried to run xdsprobe. I've never used it
before, it seems it's more
> XDS510/XDS560-oriented, anyway the command/output I give/have are in
> the following :
>
>
> /C:\CCStudio_v3.3\cc\bin> xdsprobe -f BrdDat/ccBrd0.dat -r -v/
'-r' doesn't really do anything but a JTAG reset. Try replacing
it with
'-i'.
> //
> /-----[Print the reset-command software
> log-file]-----------------------------/
> //
> /This utility has selected an XDS510 class product.
> This utility will load the adapter 'jioserdesusb.dll'.
> This utility will operate on port address '0'.
> The controller does not use a programmable FPGA.
> The emulator adapter is named 'jioserdesusb.dll'.
> The emulator adapter is titled '(null)'.
> The emulator adapter is version '(null)'.
> The emulator adapter is using 'Normal-Mode'.
> The controller has a version number of '4' (0x0004).
> The controller has an insertion length of '0' (0x0000).
> The cable+pod has a version number of '0' (0x0000).
> The cable+pod has a capability number of '0' (0x0000).
> The local memory has a base address of '0' (0x000000).
> The local memory has a word capacity of '1048576' (0x100000).
> This utility will now attempt to reset the controller.
> This utility has successfully reset the controller./
> //
> /-----[Print the reset-command hardware
> log-file]-----------------------------/
> //
> /The bridge library used to access the controller
> and adapter does not read their log-files./
> //
> /C:\CCStudio_v3.3\cc\bin>/
>
> I will send you two pictures with the dump of address 0 (DSK vs. XDS100).
> You will notice content is similar (but not identical). I see
> something wrong in the addresses.
> Instruction 02000029 (MVK.S1 0x0000,A4) is at 0x0000000C for DSK but
> it's at 0x00000008 for the XDS100 (for this last I've
subsequently
> loaded symbols to try to match the DSK picture).
> It's a mistery to me how this could happen in internal memory...
The problem is unrelated to internal memory. It is writing 'what the
JTAG logic told it to write'.
> By the way, where have you learned all this
emu-porting-related stuff ?
I worked for TI on emulation software for the C6000 family devices.
mikedunn
>
> Again, again and again, thank you in advance,
> Paolo
>
>
>
> ----- Original Message -----
> *From:* mikedunn
> *To:* p...@tin.it ; c6x
>
> *Sent:* Thursday, October 27, 2011 9:53 PM
> *Subject:* Re: R: Re: [c6x] Re: Programming TMS320C6713B
>
> Paolo,
>
> Please post to the group, not me. Others may be able to learn from
> information provided.
>
> On 10/27/2011 1:35 PM, p...@tin.it wrote:
>>
>> Hi Mike,
>> I was trying the XDS100v1 using the 6713 DSK but I have problems.
>> The connection is established and I'm able to load my program as
>> I do via USB in the same DSK board.
>> What I see in memory is anyway different, see the pictures.
>> Note that CCS doesn't report errors while I'm loading, and
in
>> both ways I get the BE (Big Endian) signal on bottom as I expect.
>> The words seems in some way "stuck", but it's just an impression
:
>> 0000082C -> 02000BE2
>> 0180002A -> 098C03AA
>> You can see they are in some way "similar" (I mean not so many
>> bits are different).
>> As this is internal memory I suppose it's not an EMIF problem.
>
> I did not see any pictures, but I think that I know what is going on.
> 1. Go to 'C:\CCStudio_v3.3\drivers\TargetDB\connections' in
> windows explorer.
> 2. There should be a file with a name something like
> 'TIXDS100_Connection.xml'. I do not remember the exact name,
but
> it will be the only connection file with XDS100 in the name.
> 3. Make a copy of the file 'just in case' and make sure that
you
> change the extension from 'xml' on the backup so that CCS will
not
> pick it up.
> 4. Just above the last line [ ''] add the following
line:
>
> Type="hiddenfield" Value="0" ID="C6000.SCANLOOP"/>
> This will disable a JTAG performance feature [called
'ScanLoop']
> that is not needed with the XDS100 and could be causing problems.
> This line is benign to all other devices, so it will not hurt to
> leave it there.
> 5. If this does not work, answer the following:
> A. If you modify internal memory from CCS, then refresh, does it
> contain the correct data??
> B. Can you run xdsprobe with the correct output??
>> Note I just made a new configuration (.ccs) for using the
>> XDS100v1 but I used the same GEL file of the DSK.
>> I also made some changes to the GEL file in order to do things
>> manually via CCs just to check some automatic action in the GEL
>> file (GEL_Reset) could cause the problem but it seems it's not
>> the case (I made reset, then init PLL, then init EMIF, then init
>> CPLD).
>> Surprisingly the DSK GEL doesn't set the PLL for the correct
>> speed (225 MHz) automatically (init_pll is available via hotmenu
>> but it's not inside an "OnXxx" function.
>> The TI GEL file is also attached (the modified one just comments
>> the GEL_Reset() inside OnPreFileLoaded).
>> Regarding the setup file (.ccs) I kept the default settings for
>> the XDS100v1, see picture.
>> I also tried with 500KHz TCLK but there is no difference on what
>> is loaded (I also tried with 5 MHz and I had the same results (as
>> I expected).
>> I really don't know how to set the other "JTAG nTRST" and
>> "Power-On-Reset Boot-Mode", I checked the electrical scheme and I
>> saw EMU0 and EMU1 are simply taken "as they are" from the DSP,
>> for this reason I kept the default (Disabled - Both EMU pins
>> remains hi-z).
>
> This is correct for the 6713 - the EMU lines should be hi-z
>>
>> So same board, same appl. program, same GEL but the XDS100v1
>> loads something different.
>> Any idea ?
>
> The C6000 emulation driver was developed over 15 years ago and I
> *think* that it may contain assumptions about the JTAG behavior of
> the emulator that does not hold true for the XDS100. This, and the
> long scan chain for the early C6000 devices are likely conspiring
> to corrupt the JTAG data.
> Please let us know your results.
>
> mikedunn
>> Thanks in advance,
>> Paolo
>> ----Messaggio originale----
>>
>> Da: m...@gmail.com
>> Data: 25-ott-2011 0.40
>> A: "Proware (tin.it)"
>> Ogg: Re: [c6x] Re: Programming TMS320C6713B
>>
>> Paolo,
>>
>> On 10/24/2011 5:04 PM, Proware (tin.it) wrote:
>>> Hi Mike, thank you!
>>>
>>> I'm trying this evening at home, but unfortunately I
don't
>>> have the target board here.
>>> Anyway, I made a configuration and tried to use it, the
>>> error I have is this one :
>>>
>>>
>>> /Error connecting to the target:
>>> Error 0x80000200/-180
>>> Fatal Error during: OCS,
>>> This error was generated by TI's USCIF driver./
>>> //
>>> /SC_ERR_CTL_NO_TRG_POWER <-180>
>>> The controller has detected a target power loss.
>>> The user must turn-on or connect the power
>>> supply for the target./
>>>
>>> //
>>> In my understanding this could be OK for now (without the
>>> target board), but you surely know much more than me on this
>>> topic.
>>
>> This is correct - no target power detected.
>>> I hope to get one of the boards this week to check it's all
>>> OK, I will let you know as soon I will make the test.
>>> May be I can use a DSK just to see the XDS100v1 is OK. If I
>>> remember well the 6713 DSK beside its internal emulator
>>> permits the connection with an external emulator, but I've
>>> never tried it in the past neither with the XDS100v1 nor
>>> with the XDS510 Plus, but I suppose that if it is there it
>>> is available/usable.
>>
>> Plugging an emulator to the 14 pin connector muxes the JTAG
>> away from the on board emulator to the 14 pin connector. It
>> should work with a DSK.
>>> I also tried without connecting the XDS100v1 to see if the
>>> error was different and it is, the one I have is :
>>>
>>>
>>> /Error connecting to the target:
>>> Error 0x80000200/-180
>>> Fatal Error during: OCS,
>>> This error was generated by TI's USCIF driver./
>>> //
>>> /SC_ERR_CTL_NO_TRG_POWER <-180>
>>> The controller has detected a target power loss.
>>> The user must turn-on or connect the power
>>> supply for the target./
>>>
>>>
>>> For my current setup this is all I can do and it's quite
>>> promising.
>>>
>>> Again, thank you!
>>>
>>>
>>> Paolo
>>>
>>>
>>>
>>> ----- Original Message -----
>>> *From:* mikedunn
>>> *To:* Proware (tin.it)
>>> *Cc:* c...
>>> *Sent:* Monday, October 24, 2011 6:24 PM
>>> *Subject:* Re: [c6x] Re: Programming TMS320C6713B
>>>
>>>
>>>
>>> Paolo,
>>>
>>>
>>> On 10/20/2011 10:31 AM, Proware (tin.it) wrote:
>>>
>>>>
>>>> Hi Mike,
>>>> we have 2 XDS510+ but I also have an XDS100v1 that
>>>> would be great for working home.
>>>> Are you sure we can use the XDS100 with the 6713?
>>>> AFAIK this is not supported (driver unavailable), in
>>>> fact it's not in the list of supported processors.
>>>> Once I read it was possible to use XDS100 with other
>>>> processors with CCS 3.3 (that is the one I'm using) via
>>>> a trick. May be it was the 64x as it is now supported
>>>> in CCS 4 and 5, but unfortunately the page I bookmarked
>>>> doesn't work anymore.
>>>
>>> I do not have access to an XDS100v1, but I will provide
>>> some info that may help.
>>>
>>> 1. It is possible that the XDS100 may not work. Without
>>> getting too detailed into the internals, I will try to
>>> explain a major difference. The newer generation devices
>>> [all c64, c28, and c55 devices] use 38 bit scan
>>> sequences for all operations. The 6713 uses an older
>>> generation scan technology that has about 3500 bits in
>>> one of the scan chains. The FTDI FT2232 device [and/or
>>> the software] may not support a buffer that large and
>>> the software to 'find the correct bits' in the
buffer.
>>> However, I do not believe that this is the case.
>>> 2. You can run an experiment to see if it works. It will
>>> definitely add the option to CCS setup.
>>>
>>> A. Make sure CCS is not running.
>>> B. Create a text file with the following contents
>>> ---next line is first line of file------
>>> <?xml version="1.0"?>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------previous line is last line----
>>>
>>> C. save the file as [make sure you save as ASCII and not
>>> Unicode].
>>> C:\CCStudio_v3.3\drivers\TargetDB\drivers\tixds100_c67xx.xml
>>> - replace 'CCStudio_v3.3' with your CCS v3.3 install
dir
>>>
>>> D. Open CCS setup and you should see 'TMS320C6710'
as
>>> one of the options.
>>> E. Try it.
>>>
>>> Please let me know if this works.
>>>
>>> Thanx,
>>> mikedunn
>>>>
>>>> Thanks in advance!
>>>> Paolo
>>>>
>>>> From Mike Dunn (in response to Herschel "Programming
>>>> TMS320C6713B"
>>>> (http://www.dsprelated.com/groups/c6x/show/14839.php):
>>>> >CCS v4 + XDS100 JTAG emulator is the most economical
>>>> approach [about
>>>> $100-150 USD].
>>>> >...Texas Instruments is offering Code Composer
>>>> Studio^(TM) for FREE for
>>>> >use with the USB100v2. Please visit the TI wiki page
>>>> for the XDS100 for
>>>> >news and details on this offer here:
>>>> >http://processors.wiki.ti.com/index.php/XDS100
>>>>
>>>
>>>
