Hi All,
I am new to TI DSPs. I have experience in Microchip's DSCs (33 series).
Right now I am in the midst of designing an audio project and selected the above
DSP. I want to know the most simplest and cost effective way to program the
TMS320C6713B. Can it be done through the UART port.
My project involves with 192k and 32 bit resolution and unable to use DSK as
this does not support.
Any document on how to program the chip would be ideal.
Thanks
Herschel
_____________________________________
Programming TMS320C6713B
Started by ●June 29, 2011
Reply by ●June 29, 20112011-06-29
Welcome aboard Herschel,
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
On 6/29/2011 9:18 AM, h...@yahoo.co.uk wrote:
>
> Hi All,
>
> I am new to TI DSPs. I have experience in Microchip's DSCs (33
> series). Right now I am in the midst of designing an audio project and
> selected the above DSP. I want to know the most simplest and cost
> effective way to program the TMS320C6713B. Can it be done through the
> UART port.
>
no.
>
> My project involves with 192k and 32 bit resolution and unable to use
> DSK as this does not support.
> Any document on how to program the chip would be ideal.
>
For 95+% of the cases it is pretty much like a micro that you program in
C. Do not waste your time trying to get a handle on the assembler out of
the gate. The biggest decision is whether to use SYS/BIOS [probably yes].
TI's C compiler is pretty good. Learn the I/Os that you will use, get a
handle on interrupts, and EDMA and you will be good to go.
NOTE: with CCS v4 and SYS/BIOS you will probably face a large learning
curve. Familiarize yourself with the tools before you start 'slinging
project code'.
mikedunn
> Thanks
>
> Herschel
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
On 6/29/2011 9:18 AM, h...@yahoo.co.uk wrote:
>
> Hi All,
>
> I am new to TI DSPs. I have experience in Microchip's DSCs (33
> series). Right now I am in the midst of designing an audio project and
> selected the above DSP. I want to know the most simplest and cost
> effective way to program the TMS320C6713B. Can it be done through the
> UART port.
>
no.
>
> My project involves with 192k and 32 bit resolution and unable to use
> DSK as this does not support.
> Any document on how to program the chip would be ideal.
>
For 95+% of the cases it is pretty much like a micro that you program in
C. Do not waste your time trying to get a handle on the assembler out of
the gate. The biggest decision is whether to use SYS/BIOS [probably yes].
TI's C compiler is pretty good. Learn the I/Os that you will use, get a
handle on interrupts, and EDMA and you will be good to go.
NOTE: with CCS v4 and SYS/BIOS you will probably face a large learning
curve. Familiarize yourself with the tools before you start 'slinging
project code'.
mikedunn
> Thanks
>
> Herschel
Reply by ●June 29, 20112011-06-29
Herschel-
Have you had a look at the C672x series? A couple are slightly faster than the C6713-300, but have substantial
advantages in onchip memory / cache amounts, peripheral support, and package size.
As these are much newer devices, online support (peer groups like this plus TI's e2e forum) is likely to be more
readily available and in-depth.
Not to say that C6713 is not a good choice, just wondering if you've checked all alternatives.
-Jeff
> Hi All,
>
> I am new to TI DSPs. I have experience in Microchip's DSCs (33 series). Right now I am in the midst of designing an
> audio project and selected the above DSP. I want to know the most simplest and cost effective way to program the
> TMS320C6713B. Can it be done through the UART port.
> My project involves with 192k and 32 bit resolution and unable to use DSK as this does not support.
> Any document on how to program the chip would be ideal.
>
> Thanks
>
> Herschel
_____________________________________
Have you had a look at the C672x series? A couple are slightly faster than the C6713-300, but have substantial
advantages in onchip memory / cache amounts, peripheral support, and package size.
As these are much newer devices, online support (peer groups like this plus TI's e2e forum) is likely to be more
readily available and in-depth.
Not to say that C6713 is not a good choice, just wondering if you've checked all alternatives.
-Jeff
> Hi All,
>
> I am new to TI DSPs. I have experience in Microchip's DSCs (33 series). Right now I am in the midst of designing an
> audio project and selected the above DSP. I want to know the most simplest and cost effective way to program the
> TMS320C6713B. Can it be done through the UART port.
> My project involves with 192k and 32 bit resolution and unable to use DSK as this does not support.
> Any document on how to program the chip would be ideal.
>
> Thanks
>
> Herschel
_____________________________________
Reply by ●June 30, 20112011-06-30
Herschel-
> Thanks for the info and I am starting all over again with C672x series.
Ok... due diligence :-)
-Jeff
> --- On Thu, 30/6/11, Jeff Brower wrote:
>
> From: Jeff Brower
> Subject: Re: [c6x] Programming TMS320C6713B
> To: c...
> Cc: h...@yahoo.co.uk
> Date: Thursday, 30 June, 2011, 0:43
>
> Herschel-
>
> Have you had a look at the C672x series? A couple are slightly faster than the C6713-300, but have substantial
> advantages in onchip memory / cache amounts, peripheral support, and package size.
>
> As these are much newer devices, online support (peer groups like this plus TI's e2e forum) is likely to be more
> readily available and in-depth.
>
> Not to say that C6713 is not a good choice, just wondering if you've checked all alternatives.
>
> -Jeff
>
>> Hi All,
>>
>> I am new to TI DSPs. I have experience in Microchip's DSCs (33 series). Right now I am in the midst of designing an
>> audio project and selected the above DSP. I want to know the most simplest and cost effective way to program the
>> TMS320C6713B. Can it be done through the UART port.
>> My project involves with 192k and 32 bit resolution and unable to use DSK as this does not support.
>> Any document on how to program the chip would be ideal.
>>
>> Thanks
>>
>> Herschel
_____________________________________
> Thanks for the info and I am starting all over again with C672x series.
Ok... due diligence :-)
-Jeff
> --- On Thu, 30/6/11, Jeff Brower wrote:
>
> From: Jeff Brower
> Subject: Re: [c6x] Programming TMS320C6713B
> To: c...
> Cc: h...@yahoo.co.uk
> Date: Thursday, 30 June, 2011, 0:43
>
> Herschel-
>
> Have you had a look at the C672x series? A couple are slightly faster than the C6713-300, but have substantial
> advantages in onchip memory / cache amounts, peripheral support, and package size.
>
> As these are much newer devices, online support (peer groups like this plus TI's e2e forum) is likely to be more
> readily available and in-depth.
>
> Not to say that C6713 is not a good choice, just wondering if you've checked all alternatives.
>
> -Jeff
>
>> Hi All,
>>
>> I am new to TI DSPs. I have experience in Microchip's DSCs (33 series). Right now I am in the midst of designing an
>> audio project and selected the above DSP. I want to know the most simplest and cost effective way to program the
>> TMS320C6713B. Can it be done through the UART port.
>> My project involves with 192k and 32 bit resolution and unable to use DSK as this does not support.
>> Any document on how to program the chip would be ideal.
>>
>> Thanks
>>
>> Herschel
_____________________________________
Reply by ●June 30, 20112011-06-30
Herschel,
I agree with Jeff that the c672x is a much better choice than the older
c671x devices.
mikedunn
On 6/30/2011 11:24 AM, Jeff Brower wrote:
>
> Herschel-
>
> > Thanks for the info and I am starting all over again with C672x series.
>
> Ok... due diligence :-)
>
> -Jeff
>
> > --- On Thu, 30/6/11, Jeff Brower > > wrote:
> >
> > From: Jeff Brower > >
> > Subject: Re: [c6x] Programming TMS320C6713B
> > To: c...
> > Cc: h...@yahoo.co.uk
>
> > Date: Thursday, 30 June, 2011, 0:43
> >
> > Herschel-
> >
> > Have you had a look at the C672x series? A couple are slightly
> faster than the C6713-300, but have substantial
> > advantages in onchip memory / cache amounts, peripheral support, and
> package size.
> >
> > As these are much newer devices, online support (peer groups like
> this plus TI's e2e forum) is likely to be more
> > readily available and in-depth.
> >
> > Not to say that C6713 is not a good choice, just wondering if you've
> checked all alternatives.
> >
> > -Jeff
> >
> >> Hi All,
> >>
> >> I am new to TI DSPs. I have experience in Microchip's DSCs (33
> series). Right now I am in the midst of designing an
> >> audio project and selected the above DSP. I want to know the most
> simplest and cost effective way to program the
> >> TMS320C6713B. Can it be done through the UART port.
> >> My project involves with 192k and 32 bit resolution and unable to
> use DSK as this does not support.
> >> Any document on how to program the chip would be ideal.
> >>
> >> Thanks
> >>
> >> Herschel
> >
> >
I agree with Jeff that the c672x is a much better choice than the older
c671x devices.
mikedunn
On 6/30/2011 11:24 AM, Jeff Brower wrote:
>
> Herschel-
>
> > Thanks for the info and I am starting all over again with C672x series.
>
> Ok... due diligence :-)
>
> -Jeff
>
> > --- On Thu, 30/6/11, Jeff Brower > > wrote:
> >
> > From: Jeff Brower > >
> > Subject: Re: [c6x] Programming TMS320C6713B
> > To: c...
> > Cc: h...@yahoo.co.uk
>
> > Date: Thursday, 30 June, 2011, 0:43
> >
> > Herschel-
> >
> > Have you had a look at the C672x series? A couple are slightly
> faster than the C6713-300, but have substantial
> > advantages in onchip memory / cache amounts, peripheral support, and
> package size.
> >
> > As these are much newer devices, online support (peer groups like
> this plus TI's e2e forum) is likely to be more
> > readily available and in-depth.
> >
> > Not to say that C6713 is not a good choice, just wondering if you've
> checked all alternatives.
> >
> > -Jeff
> >
> >> Hi All,
> >>
> >> I am new to TI DSPs. I have experience in Microchip's DSCs (33
> series). Right now I am in the midst of designing an
> >> audio project and selected the above DSP. I want to know the most
> simplest and cost effective way to program the
> >> TMS320C6713B. Can it be done through the UART port.
> >> My project involves with 192k and 32 bit resolution and unable to
> use DSK as this does not support.
> >> Any document on how to program the chip would be ideal.
> >>
> >> Thanks
> >>
> >> Herschel
> >
> >
Reply by ●October 20, 20112011-10-20
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.
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
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.
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
Reply by ●October 20, 20112011-10-20
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 am pretty sure that I have used 'some version' of the XDS100 with
'some version' of the 6713 and CCS v3 in the past. I am not where I can
look at it today, but I will try to check it out sometime tomorrow. I
cannot think of any technical reason for it not to work - at the most, I
would expect that it might require a custom CCS setup file.
If you do not see anything from me by Monday, feel free to post 'Any
progress yet??'
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
>
>
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 am pretty sure that I have used 'some version' of the XDS100 with
'some version' of the 6713 and CCS v3 in the past. I am not where I can
look at it today, but I will try to check it out sometime tomorrow. I
cannot think of any technical reason for it not to work - at the most, I
would expect that it might require a custom CCS setup file.
If you do not see anything from me by Monday, feel free to post 'Any
progress yet??'
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
>
>
Reply by ●October 24, 20112011-10-24
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
>
>
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
>
>
Reply by ●November 4, 20112011-11-04
Thank you Richard I appreciate your help, but in any case see Mike's
response.
If you generate the listing, you see it's just a sequence of bytes (no lib, no
main, no anything else), and indeed it was very good for checking where the
problem lies:
DSK USB XDS100v1
DSK in LE and program compiled in LE : OK OK
DSK in BE and program compiled in BE : OK NOK
It seems (to me) the driver for the XDS100v1 has something "wired" to little
endian.
As Mike said, and I've checked, the DSK USB emulator driver comes from Spectrum
Digital, while the XDS100's one is from TI. As SD sells the entire DSK, and it
permits to set the endianity via a switch on the motherboard, it's quite normal
they permit to develop SW in both endianities and their driver is able to cope
with this.
If you see last response from Mike, he will possibly check 'tixds6000.dvr' vs.
'tixds560c6x.dvr'. May be the driver for the XDS100 (tixds6000.dvr) is different
from the one for XDS560. I think that beside the obvious differences regarding
the HW of the underlying emulators, there could be other differences : I suppose
the 'tixds6000.dvr' is also "low cost" (I mean TI surely put more effort on the
XDS560), so something, including endianity handling, is missing/not completely
supported.
As we are lucky to have "Mike the wizard" in the c6x group, may be he'll be able
to set the final statement on the subject... if he's not busy with halloween
(pumpkin animated by a cluster of c6000 ?, No, cluster of pumpkins amimated by
clusters of c6000's).
Have a nice halloween!
Paolo
----- Original Message -----
From: "mikedunn"
To: "Richard Williams"
Cc: "Proware (tin.it)" ; "c6x"
Sent: Saturday, October 29, 2011 9:50 PM
Subject: Re: R: Re: [c6x] Re: Programming TMS320C6713B
> Hello Richard,
>
> The code with 'mystart' doesn't execute - I am the guilty party that
> tossed it out without a proper LCF. It is a quick and dirty asm file
> that does not use any libs and just generates sequential patterns to
> load into memory for troubleshooting 'load problems'.
>
> mikedunn
>
> On 10/29/2011 3:19 PM, Richard Williams wrote:
>> Proware,
>>
>> From your code, it seems that you are not using the appropriate runtime
>> library.
>> With the runtime library, ram initialization, CSx setup, and much much more
>> will
>> be taken care of by the library initialization functions.
>> Amongst those functions is the _c_int00 entry point.
>> also, if you name 'mystart()' as 'main()' in the source code, (which is what
>> the
>> linker/runtime library expects) then things will go much easier with you.
>>
>> Your linker file needs to include the 'vectors' file and the appropriate
>> commands to place that file at the beginning of the interrupt vectors table.
>> BTW:
>> _c_int00 is the entry point of a function to handle interrupt 0 (reset)
>> the run time library contains a function start() which has the _c_int00 entry
>> point defined. (the source code for start is also provided, if you want to
>> modify it.)
>>
>> the .cmd file needs all lot more info than what you have shown in the
>> example.
>> Perhaps it would be easier, at least as a startpoint, to have the CCS
>> generate
>> the linker command file. You can always expand/modify that file to suit your
>> specific needs.
>>
>> I might suggest even going to the ./examples directory and using one of the
>> provided .cmd files as a start point for your non-BIOS project.
>>
>> If I remember correctly, the linker leaves room for the 'reset' vector, even
>> if
>> it is not specifically provided for in the code.
>> That is why you see the .text segment offset of 0x20.
>>
>> If you include the 'vectors file and use a complete .cmd file, then the
>> vectors
>> file will overlay the interrupt vector table.
>> If you use the runtime library (which one depends on which 'endian' you use)
>> then the _c_int00 label will be properly defined.
>> If you name the first function to be executed in your program 'main() then
>> the
>> runtime library will know how to find/execute it.
>>
>> BTW:
>> From you description, it seems your trying to load a object file (results of
>> a
>> compile operation) rather than a executable image file (requires taking a
>> linked
>> file and passing it through the 'HEXxxx' utility with appropriate parameters
>> for
>> your target system.
>> R. Williams
>> ---------- Original Message -----------
>> From: mike ocase the load succeeds, ehm proceeds... up to to the end
>>>> address. Anyway the content is also not aligned to what I expected,
>>>> i.e. at address 0x00000020 I have 0x04050607 (i.o. 0x00010203). Data
>>>> verification failed at 0x20.
>>>> I tried other times. It seems data is loaded in blocks, I mean I see
>>>> data with some sequencing for all the 1K bytes as if the loading sets
>>>> the error address at the beginning of a block (or writes an
>>>> entire block before verifying it).
>>>> Data messing is in every part of the memory, e.g. in one of the tests
>>>> I checked address 0x000000A0 (0x84858687, OK).
>>>> Then I see 0x8C8D8E8F twice (i.e. 0x88898A8B and 0x8C8D8E8F), then
>>>> 0x9C9D9E9F (i.o. 0x90919293), 0x94959697 (OK), 0x9C9D9E9F (i.o
>>>> 0x98999A9B), 0x9C9D9E9F (OK), 0xBCBDBEBF...
>>>>
>>>> Then I made a linker command file (.cmd) just to avoid the 0x20 offset.
>>>> ----------------first line below----------
>>>> MEMORY
>>>> {
>>>> L2SRAM : o = 00000000h l = 00030000h
>>>> EXTERNAL: o = 80000000h l = 01000000h
>>>> }
>>>>
>>>> SECTIONS
>>>> {
>>>> .text > L2SRAM
>>>> }
>>>> ----------------last line above----------
>>>> and I tried to reload (each time I do this I fill memory with 0 to
>>>> exactly see what happens).
>>>> The dump is in the following
>>>> -- C6713 DSK/TMS320C6713 --
>>>> 0x00000000 0x04050607 0x0C0D0E0F
>>>> 0x00000008 0x0C0D0E0F 0x1C1D1E1F
>>>> 0x00000010 0x14151617 0x1C1D1E1F
>>>> 0x00000018 0x1C1D1E1F 0x3C3D3E3F
>>>> 0x00000020 0x24252627 0x2C2D2E2F
>>>> 0x00000028 0x2C2D2E2F 0x3C3D3E3F
>>>> 0x00000030 0x34353637 0x3C3D3E3F
>>>> 0x00000038 0x3C3D3E3F 0x7C7D7E7F
>>>> 0x00000040 0x44454647 0x4C4D4E4F
>>>> 0x00000048 0x4C4D4E4F 0x5C5D5E5F
>>>> 0x00000050 0x54555657 0x5C5D5E5F
>>>> 0x00000058 0x5C5D5E5F 0x7C7D7E7F
>>>> 0x00000060 0x64656667 0x6C6D6E6F
>>>> 0x00000068 0x6C6D6E6F 0x7C7D7E7F
>>>> 0x00000070 0x74757677 0x7C7D7E7F
>>>> 0x00000078 0x7C7D7E7F 0xFCFDFEFF
>>>> 0x00000080 0x84858687 0x8C8D8E8F
>>>> 0x00000088 0x8C8D8E8F 0x9C9D9E9F
>>>> 0x00000090 0x94959697 0x9C9D9E9F
>>>> 0x00000098 0x9C9D9E9F 0xBCBDBEBF
>>>> 0x000000A0 0xA4A5A6A7 0xACADAEAF
>>>> 0x000000A8 0xACADAEAF 0xBCBDBEBF
>>>> 0x000000B0 0xB4B5B6B7 0xBCBDBEBF
>>>> 0x000000B8 0xBCBDBEBF 0xFCFDFEFF
>>>> -- Copyright © 2011 Texas Instruments -- Page 1 of 1
>>>> Again, the first word is missing. I see some rule in data messing :
>>>> 0x000000X0 0xX4x5X6X7 repeated every 0x10, data is
>>>> + 4,
>>>> I never see word 0xX0X1X2X3
>>>> 0x000000X4 0xXCXDXEXF repeated every 0x10, data is
>>>> + 8, word 0xX4X5X6X7 is at addr-4
>>>> 0x000000X8 0xXCXDXEXF repeated every 0x10, data is
>>>> + 4,
>>>> I never see word 0xX8X9XAXB
>>>> (similar to addr 0x000000X0)
>>>> 0x000000XC 0xXCXDXEXF repeated every 0x10, data is OK
>>>>
>>>> Now the good news. [at least for some people] :-)
>>>> Even if I thought there was something bad with the latching of the
>>>> address, I tried again re-building in little endian (and obviously
>>>> restoring the DSK to little endian via switch SW3-1).
>>>> It works. Obviously I see data in LE, I mean if I dump words I see
>>>> 0x03020100 and not 0x00010203, but this is what I was expecting as the
>>>> asm source uses bytes.
>>>> I've modified the asm file to use the entire (0x00030000) IRAM and
>>>> it's OK.
>>>> ----------------mod line below----------
>>>> mystart:
>>>> ; .asg 4,CNT ;size of outer loop (256 x 4 = 1KB)
>>>> .asg 768,CNT ;size of outer loop (entire IRAM, 256
>>>> x 768 = 0x00030000)
>>>> ----------------mod line above----------
>>>> Then I tried also in external memory by modifying the linker command
>>>> file (.text > EXTERNAL) and it's OK.
>>>> Now I've unleashed the emulator to it's full speed via CCS setup
>>>> (selected "Fixed with user specified faster value" for JTAG TCLK freq.
>>>> and set "6.0MHz" in Enter a value... field). Yet another OK. Load time
>>>> for the 192KB block in both IRAM and ext SDRAM is about 22 sec (I
>>>> suppose the bottleneck is data xfer via JTAG not the target memory)
>>>> versus the 25-26 sec I have with the default 1MHz TCLK. Not a big
>>>> improvement for a x6 TCLK (as far as memory loading is concerned).
>>>
>>> More expensive emulators use hardware to manage the JTAG state machine
>>> and 'other stuff'. The XDS100 does this in software and that is
>>> probably more of the bottleneck than the JTAG clock rate.
>>>> Regarding memory filling via CCS, I noticed the beginning of the fill
>>>> phase in IRAM has about the same speed as with 1MHz, but at a certain
>>>> point... the filling lifts off (the blu advancement blocks in the
>>>> popup go to the the end in about one second). May be I didn't notice
>>>> this at 1 MHz (the speed for filling the ext SDRAM seems quite the
>>>> same, no lift off).
>>>
>>> Things like fill memory are 'blocked up' and are one of the things that
>>> the 'scanloop' option uses to improve performance. It will be slower
>>> with that option disabled.
>>>>
>>>> Now the bad news.
>>>> I do not consider the problem completely solved, as my board is big
>>>> endian. I will check with the HW guy but I think that's fixed. In any
>>>> case the setting of the external peripherals should be modified in
>>>> order to deal with the reversed endianity : not all the SW is
>>>> endianity-aware (it shouldn't cost you so much if this is taken into
>>>> account from the beginning... by all the SW developers...
>>>> Mike, may be I'm wrong, but I suppose the 'JTAG clock edge' can be
>>>> considered OK.
>>>
>>> With a simple and cleanly designed scan chain, testing has shown that
>>> higher reliable scan rates can be attained by using the rising edge of
>>> the JTAG clock as opposed to the falling edge as defined by the JTAG
>>> standard. It is always safe to use the JTAG standard setting -
>>> especially when we are not trying to push the speed limits. Now that I
>>> think about, I do not know if they gave you the option on the XDS100.
>>>> But what about endianity ?
>>>
>>> endianness
>>> I believe that when connecting through the DSK USB port you are using a
>>> SD driver and when you connect with XDS100, you are using a TI driver.
>>> It sounds like a sw problem. If I remember correctly-
>>> DSK w/on board USB emulator, big endian - works
>>> DSK w/on board USB emulator, little endian - works
>>> DSK w/external USB emulator, big endian - works
>>> DSK w/external USB emulator, little endian - works
>>> DSK w/XDS100 emulator, big endian - does not work
>>> DSK w/XDS100 emulator, little endian - works
>>> Do the above accurately reflect the current state??
>>>
>>>> I remember Processor Properties for the simulator includes Endianness
>>>> setting, but this is not available/needed for most of the cases. As
>>>> example with the DSK USB Emulator I do work with both endianity
>>>> setting with no problem : just set SW3-1 as you want and choose the
>>>> related Endianness setting for the Compiler Build Option (it's under
>>>> the Advanced tab).
>>>> Only the "6713 DSK Diagnostics Utility v3.1" program needs little
>>>> endian setting (it fails in big endian).
>>>>
>>>>
>>>> Thank you very much.
>>>> Paolo
>>>>
>>>> ----- Original Message -----
>>>> *From:* mikedunn
>>>> *To:* Proware (tin.it)
>>>> *Cc:* c6x
>>>> *Sent:* Saturday, October 29, 2011 12:46 AM
>>>> *Subject:* Re: R: Re: [c6x] Re: Programming TMS320C6713B
>>>>
>>>> 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
>>>>>
>> ------- End of Original Message -------
>
_____________________________________
If you generate the listing, you see it's just a sequence of bytes (no lib, no
main, no anything else), and indeed it was very good for checking where the
problem lies:
DSK USB XDS100v1
DSK in LE and program compiled in LE : OK OK
DSK in BE and program compiled in BE : OK NOK
It seems (to me) the driver for the XDS100v1 has something "wired" to little
endian.
As Mike said, and I've checked, the DSK USB emulator driver comes from Spectrum
Digital, while the XDS100's one is from TI. As SD sells the entire DSK, and it
permits to set the endianity via a switch on the motherboard, it's quite normal
they permit to develop SW in both endianities and their driver is able to cope
with this.
If you see last response from Mike, he will possibly check 'tixds6000.dvr' vs.
'tixds560c6x.dvr'. May be the driver for the XDS100 (tixds6000.dvr) is different
from the one for XDS560. I think that beside the obvious differences regarding
the HW of the underlying emulators, there could be other differences : I suppose
the 'tixds6000.dvr' is also "low cost" (I mean TI surely put more effort on the
XDS560), so something, including endianity handling, is missing/not completely
supported.
As we are lucky to have "Mike the wizard" in the c6x group, may be he'll be able
to set the final statement on the subject... if he's not busy with halloween
(pumpkin animated by a cluster of c6000 ?, No, cluster of pumpkins amimated by
clusters of c6000's).
Have a nice halloween!
Paolo
----- Original Message -----
From: "mikedunn"
To: "Richard Williams"
Cc: "Proware (tin.it)" ; "c6x"
Sent: Saturday, October 29, 2011 9:50 PM
Subject: Re: R: Re: [c6x] Re: Programming TMS320C6713B
> Hello Richard,
>
> The code with 'mystart' doesn't execute - I am the guilty party that
> tossed it out without a proper LCF. It is a quick and dirty asm file
> that does not use any libs and just generates sequential patterns to
> load into memory for troubleshooting 'load problems'.
>
> mikedunn
>
> On 10/29/2011 3:19 PM, Richard Williams wrote:
>> Proware,
>>
>> From your code, it seems that you are not using the appropriate runtime
>> library.
>> With the runtime library, ram initialization, CSx setup, and much much more
>> will
>> be taken care of by the library initialization functions.
>> Amongst those functions is the _c_int00 entry point.
>> also, if you name 'mystart()' as 'main()' in the source code, (which is what
>> the
>> linker/runtime library expects) then things will go much easier with you.
>>
>> Your linker file needs to include the 'vectors' file and the appropriate
>> commands to place that file at the beginning of the interrupt vectors table.
>> BTW:
>> _c_int00 is the entry point of a function to handle interrupt 0 (reset)
>> the run time library contains a function start() which has the _c_int00 entry
>> point defined. (the source code for start is also provided, if you want to
>> modify it.)
>>
>> the .cmd file needs all lot more info than what you have shown in the
>> example.
>> Perhaps it would be easier, at least as a startpoint, to have the CCS
>> generate
>> the linker command file. You can always expand/modify that file to suit your
>> specific needs.
>>
>> I might suggest even going to the ./examples directory and using one of the
>> provided .cmd files as a start point for your non-BIOS project.
>>
>> If I remember correctly, the linker leaves room for the 'reset' vector, even
>> if
>> it is not specifically provided for in the code.
>> That is why you see the .text segment offset of 0x20.
>>
>> If you include the 'vectors file and use a complete .cmd file, then the
>> vectors
>> file will overlay the interrupt vector table.
>> If you use the runtime library (which one depends on which 'endian' you use)
>> then the _c_int00 label will be properly defined.
>> If you name the first function to be executed in your program 'main() then
>> the
>> runtime library will know how to find/execute it.
>>
>> BTW:
>> From you description, it seems your trying to load a object file (results of
>> a
>> compile operation) rather than a executable image file (requires taking a
>> linked
>> file and passing it through the 'HEXxxx' utility with appropriate parameters
>> for
>> your target system.
>> R. Williams
>> ---------- Original Message -----------
>> From: mike ocase the load succeeds, ehm proceeds... up to to the end
>>>> address. Anyway the content is also not aligned to what I expected,
>>>> i.e. at address 0x00000020 I have 0x04050607 (i.o. 0x00010203). Data
>>>> verification failed at 0x20.
>>>> I tried other times. It seems data is loaded in blocks, I mean I see
>>>> data with some sequencing for all the 1K bytes as if the loading sets
>>>> the error address at the beginning of a block (or writes an
>>>> entire block before verifying it).
>>>> Data messing is in every part of the memory, e.g. in one of the tests
>>>> I checked address 0x000000A0 (0x84858687, OK).
>>>> Then I see 0x8C8D8E8F twice (i.e. 0x88898A8B and 0x8C8D8E8F), then
>>>> 0x9C9D9E9F (i.o. 0x90919293), 0x94959697 (OK), 0x9C9D9E9F (i.o
>>>> 0x98999A9B), 0x9C9D9E9F (OK), 0xBCBDBEBF...
>>>>
>>>> Then I made a linker command file (.cmd) just to avoid the 0x20 offset.
>>>> ----------------first line below----------
>>>> MEMORY
>>>> {
>>>> L2SRAM : o = 00000000h l = 00030000h
>>>> EXTERNAL: o = 80000000h l = 01000000h
>>>> }
>>>>
>>>> SECTIONS
>>>> {
>>>> .text > L2SRAM
>>>> }
>>>> ----------------last line above----------
>>>> and I tried to reload (each time I do this I fill memory with 0 to
>>>> exactly see what happens).
>>>> The dump is in the following
>>>> -- C6713 DSK/TMS320C6713 --
>>>> 0x00000000 0x04050607 0x0C0D0E0F
>>>> 0x00000008 0x0C0D0E0F 0x1C1D1E1F
>>>> 0x00000010 0x14151617 0x1C1D1E1F
>>>> 0x00000018 0x1C1D1E1F 0x3C3D3E3F
>>>> 0x00000020 0x24252627 0x2C2D2E2F
>>>> 0x00000028 0x2C2D2E2F 0x3C3D3E3F
>>>> 0x00000030 0x34353637 0x3C3D3E3F
>>>> 0x00000038 0x3C3D3E3F 0x7C7D7E7F
>>>> 0x00000040 0x44454647 0x4C4D4E4F
>>>> 0x00000048 0x4C4D4E4F 0x5C5D5E5F
>>>> 0x00000050 0x54555657 0x5C5D5E5F
>>>> 0x00000058 0x5C5D5E5F 0x7C7D7E7F
>>>> 0x00000060 0x64656667 0x6C6D6E6F
>>>> 0x00000068 0x6C6D6E6F 0x7C7D7E7F
>>>> 0x00000070 0x74757677 0x7C7D7E7F
>>>> 0x00000078 0x7C7D7E7F 0xFCFDFEFF
>>>> 0x00000080 0x84858687 0x8C8D8E8F
>>>> 0x00000088 0x8C8D8E8F 0x9C9D9E9F
>>>> 0x00000090 0x94959697 0x9C9D9E9F
>>>> 0x00000098 0x9C9D9E9F 0xBCBDBEBF
>>>> 0x000000A0 0xA4A5A6A7 0xACADAEAF
>>>> 0x000000A8 0xACADAEAF 0xBCBDBEBF
>>>> 0x000000B0 0xB4B5B6B7 0xBCBDBEBF
>>>> 0x000000B8 0xBCBDBEBF 0xFCFDFEFF
>>>> -- Copyright © 2011 Texas Instruments -- Page 1 of 1
>>>> Again, the first word is missing. I see some rule in data messing :
>>>> 0x000000X0 0xX4x5X6X7 repeated every 0x10, data is
>>>> + 4,
>>>> I never see word 0xX0X1X2X3
>>>> 0x000000X4 0xXCXDXEXF repeated every 0x10, data is
>>>> + 8, word 0xX4X5X6X7 is at addr-4
>>>> 0x000000X8 0xXCXDXEXF repeated every 0x10, data is
>>>> + 4,
>>>> I never see word 0xX8X9XAXB
>>>> (similar to addr 0x000000X0)
>>>> 0x000000XC 0xXCXDXEXF repeated every 0x10, data is OK
>>>>
>>>> Now the good news. [at least for some people] :-)
>>>> Even if I thought there was something bad with the latching of the
>>>> address, I tried again re-building in little endian (and obviously
>>>> restoring the DSK to little endian via switch SW3-1).
>>>> It works. Obviously I see data in LE, I mean if I dump words I see
>>>> 0x03020100 and not 0x00010203, but this is what I was expecting as the
>>>> asm source uses bytes.
>>>> I've modified the asm file to use the entire (0x00030000) IRAM and
>>>> it's OK.
>>>> ----------------mod line below----------
>>>> mystart:
>>>> ; .asg 4,CNT ;size of outer loop (256 x 4 = 1KB)
>>>> .asg 768,CNT ;size of outer loop (entire IRAM, 256
>>>> x 768 = 0x00030000)
>>>> ----------------mod line above----------
>>>> Then I tried also in external memory by modifying the linker command
>>>> file (.text > EXTERNAL) and it's OK.
>>>> Now I've unleashed the emulator to it's full speed via CCS setup
>>>> (selected "Fixed with user specified faster value" for JTAG TCLK freq.
>>>> and set "6.0MHz" in Enter a value... field). Yet another OK. Load time
>>>> for the 192KB block in both IRAM and ext SDRAM is about 22 sec (I
>>>> suppose the bottleneck is data xfer via JTAG not the target memory)
>>>> versus the 25-26 sec I have with the default 1MHz TCLK. Not a big
>>>> improvement for a x6 TCLK (as far as memory loading is concerned).
>>>
>>> More expensive emulators use hardware to manage the JTAG state machine
>>> and 'other stuff'. The XDS100 does this in software and that is
>>> probably more of the bottleneck than the JTAG clock rate.
>>>> Regarding memory filling via CCS, I noticed the beginning of the fill
>>>> phase in IRAM has about the same speed as with 1MHz, but at a certain
>>>> point... the filling lifts off (the blu advancement blocks in the
>>>> popup go to the the end in about one second). May be I didn't notice
>>>> this at 1 MHz (the speed for filling the ext SDRAM seems quite the
>>>> same, no lift off).
>>>
>>> Things like fill memory are 'blocked up' and are one of the things that
>>> the 'scanloop' option uses to improve performance. It will be slower
>>> with that option disabled.
>>>>
>>>> Now the bad news.
>>>> I do not consider the problem completely solved, as my board is big
>>>> endian. I will check with the HW guy but I think that's fixed. In any
>>>> case the setting of the external peripherals should be modified in
>>>> order to deal with the reversed endianity : not all the SW is
>>>> endianity-aware (it shouldn't cost you so much if this is taken into
>>>> account from the beginning... by all the SW developers...
>>>> Mike, may be I'm wrong, but I suppose the 'JTAG clock edge' can be
>>>> considered OK.
>>>
>>> With a simple and cleanly designed scan chain, testing has shown that
>>> higher reliable scan rates can be attained by using the rising edge of
>>> the JTAG clock as opposed to the falling edge as defined by the JTAG
>>> standard. It is always safe to use the JTAG standard setting -
>>> especially when we are not trying to push the speed limits. Now that I
>>> think about, I do not know if they gave you the option on the XDS100.
>>>> But what about endianity ?
>>>
>>> endianness
>>> I believe that when connecting through the DSK USB port you are using a
>>> SD driver and when you connect with XDS100, you are using a TI driver.
>>> It sounds like a sw problem. If I remember correctly-
>>> DSK w/on board USB emulator, big endian - works
>>> DSK w/on board USB emulator, little endian - works
>>> DSK w/external USB emulator, big endian - works
>>> DSK w/external USB emulator, little endian - works
>>> DSK w/XDS100 emulator, big endian - does not work
>>> DSK w/XDS100 emulator, little endian - works
>>> Do the above accurately reflect the current state??
>>>
>>>> I remember Processor Properties for the simulator includes Endianness
>>>> setting, but this is not available/needed for most of the cases. As
>>>> example with the DSK USB Emulator I do work with both endianity
>>>> setting with no problem : just set SW3-1 as you want and choose the
>>>> related Endianness setting for the Compiler Build Option (it's under
>>>> the Advanced tab).
>>>> Only the "6713 DSK Diagnostics Utility v3.1" program needs little
>>>> endian setting (it fails in big endian).
>>>>
>>>>
>>>> Thank you very much.
>>>> Paolo
>>>>
>>>> ----- Original Message -----
>>>> *From:* mikedunn
>>>> *To:* Proware (tin.it)
>>>> *Cc:* c6x
>>>> *Sent:* Saturday, October 29, 2011 12:46 AM
>>>> *Subject:* Re: R: Re: [c6x] Re: Programming TMS320C6713B
>>>>
>>>> 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
>>>>>
>> ------- End of Original Message -------
>
_____________________________________
Reply by ●November 4, 20112011-11-04
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 bookmarked page doesn't work anymore.
Thanks in advance!
Paolo
>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
_____________________________________
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 bookmarked page doesn't work anymore.
Thanks in advance!
Paolo
>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
_____________________________________
