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