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"
warning: entry-point symbol other than "_c_int00" specified: "mystart"
Build Complete,
0 Errors, 2 Warnings, 0 Remarks.
but the .out has been created (even without the linker command file).
For what I see the default start address for .text is at address 0x00000020 (not
0).
In this case 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).
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).
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.
But what about endianity ?
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
