Paolo,
On 10/29/2011 6:29 AM, Proware (tin.it) wrote:
> Hi Mike, I made the test.
> No warning while compiling, I just get an error while building because
> there is no "main" (unsresolved _main).
> I've modified the linker options to set the Code entry point to
> "mystart" (-e option).
> A pair of warnings remain :
>
> /-------------------------- LoadTest_PT.pjt - Debug
> --------------------------
> Warning: The project has no cmd file while the Text Linker is selected
> [Linking...] "C:\CCStudio_v3.3\C6000\cgtools6.1.13\bin\cl6x"
> //-@"Debug.lkf/
©
'
'
'
''
''
'
''
''
'
'
'''
'
'
'
'
''
'
'
'
''
''
''''
''
''
'''
''
''
''
''
''
''
''
''
''
''
''
''
''
''
'
'
'
Re: R: Re: Re: Programming TMS320C6713B
Started by ●October 29, 2011
Reply by ●October 29, 20112011-10-29
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 -------
_____________________________________
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 ●October 29, 20112011-10-29
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 -------
>
_____________________________________
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 -------
>
_____________________________________
