Re: R: Re: Re: Programming TMS320C6713B

Started by "Proware (tin.it)" October 29, 2011
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----------
L2SRAM : o = 00000000h l = 00030000h
EXTERNAL: o = 80000000h l = 01000000h

.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
0x000000B0 0xB4B5B6B7 0xBCBDBEBF
-- 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----------
; .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.

----- 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

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

;code start
.asg 4,CNT ;size of outer loop
.loop CNT
bitinc ; inner loop macro
.eval CNT - 1, CNT ; update loop count
;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.


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.

Again, again and again, thank you in advance,