Paolo,
On 10/31/2011 6:06 AM, Proware (tin.it) wrote:
> Thank you Richard I appreciate your help, but in any
case see Mike's
> response.
> If you generate the listing, you see it's just a sequence of bytes (no
> lib, no main, no anything else), and indeed it was very good for
> checking where the problem lies:
>
> DSK USB XDS100v1
> DSK in LE and program compiled in LE : OK OK
> DSK in BE and program compiled in BE : OK NOK
>
> It seems (to me) the driver for the XDS100v1 has something "wired" to
> little endian.
> As Mike said, and I've checked, the DSK USB emulator driver comes from
> Spectrum Digital, while the XDS100's one is from TI. As SD sells the
> entire DSK, and it permits to set the endianity via a switch on the
> motherboard, it's quite normal they permit to develop SW in both
> endianities and their driver is able to cope with this.
> If you see last response from Mike, he will possibly check
> 'tixds6000.dvr' vs. 'tixds560c6x.dvr'. May be the driver
for the
> XDS100 (tixds6000.dvr) is different from the one for XDS560. I think
> that beside the obvious differences regarding the HW of the underlying
> emulators, there could be other differences : I suppose the
> 'tixds6000.dvr' is also "low cost" (I mean TI surely put more
effort
> on the XDS560), so something, including endianity handling, is
> missing/not completely supported.
Actually the 'tixds6000.dvr' is the XDS510 driver [the original
C6000
driver] and the 'tixds560c6x.dvr' is derived from it - they are
built
from the same code base. I am tending to some other business today. My
goal is to run the 'tixds6000.dvr' on an an XDS560 [faking an XDS510]
to
see if the problem is in the 'tixds6000.dvr'. I suspect that it is
not
and is a bug in the XDS100v1 - probably why TI did not support C6000 and
released the XDS100v2 [which includes hw and sw changes and is only
supported on CCS v4. We shall see.
mikedunn
>
> As we are lucky to have "Mike the wizard" in the c6x group, may be
> he'll be able to set the final statement on the subject... if he's
not
> busy with halloween (pumpkin animated by a cluster of c6000 ?, No,
> cluster of pumpkins amimated by clusters of c6000's).
>
> Have a nice halloween!
> Paolo
>
> ----- Original Message ----- From: "mikedunn"
> To: "Richard Williams"
> Cc: "Proware (tin.it)" ; "c6x"
> Sent: Saturday, October 29, 2011 9:50 PM
> Subject: Re: R: Re: [c6x] Re: Programming TMS320C6713B
>> Hello Richard,
>>
>> The code with 'mystart' doesn't execute - I am the guilty
party that
>> tossed it out without a proper LCF. It is a quick and dirty asm file
>> that does not use any libs and just generates sequential patterns to
>> load into memory for troubleshooting 'load problems'.
>>
>> mikedunn
>>
>> On 10/29/2011 3:19 PM, Richard Williams wrote:
>>> Proware,
>>>
>>> From your code, it seems that you are not using the appropriate
>>> runtime library.
>>> With the runtime library, ram initialization, CSx setup, and much
>>> much more will
>>> be taken care of by the library initialization functions.
>>> Amongst those functions is the _c_int00 entry point.
>>> also, if you name 'mystart()' as 'main()' in the source
code, (which
>>> is what the
>>> linker/runtime library expects) then things will go much easier with
>>> you.
>>>
>>> Your linker file needs to include the 'vectors' file and the
>>> appropriate
>>> commands to place that file at the beginning of the interrupt
>>> vectors table.
>>> BTW:
>>> _c_int00 is the entry point of a function to handle interrupt 0 (reset)
>>> the run time library contains a function start() which has the
>>> _c_int00 entry
>>> point defined. (the source code for start is also provided, if you
>>> want to
>>> modify it.)
>>>
>>> the .cmd file needs all lot more info than what you have shown in
>>> the example.
>>> Perhaps it would be easier, at least as a startpoint, to have the
>>> CCS generate
>>> the linker command file. You can always expand/modify that file to
>>> suit your
>>> specific needs.
>>>
>>> I might suggest even going to the ./examples directory and using one
>>> of the
>>> provided .cmd files as a start point for your non-BIOS project.
>>>
>>> If I remember correctly, the linker leaves room for the 'reset'
>>> vector, even if
>>> it is not specifically provided for in the code.
>>> That is why you see the .text segment offset of 0x20.
>>>
>>> If you include the 'vectors file and use a complete .cmd file, then
>>> the vectors
>>> file will overlay the interrupt vector table.
>>> If you use the runtime library (which one depends on which
'endian'
>>> you use)
>>> then the _c_int00 label will be properly defined.
>>> If you name the first function to be executed in your program
>>> 'main() then the
>>> runtime library will know how to find/execute it.
>>>
>>> BTW:
>>> From you description, it seems your trying to load a object file
>>> (results of a
>>> compile operation) rather than a executable image file (requires
>>> taking a linked
>>> file and passing it through the 'HEXxxx' utility with
appropriate
>>> parameters for
>>> your target system.
>>>
>>>
>>> R. Williams
>>>
>>>
>>> ---------- Original Message -----------
>>> From: mike ocase the load succeeds, ehm proceeds... up to to the end
>>>>> address. Anyway the content is also not aligned to what I expected,
>>>>> i.e. at address 0x00000020 I have 0x04050607 (i.o. 0x00010203). Data
>>>>> verification failed at 0x20.
>>>>> I tried other times. It seems data is loaded in blocks, I mean I see
>>>>> data with some sequencing for all the 1K bytes as if the loading sets
>>>>> the error address at the beginning of a block (or writes an
>>>>> entire block before verifying it).
>>>>> Data messing is in every part of the memory, e.g. in one of the tests
>>>>> I checked address 0x000000A0 (0x84858687, OK).
>>>>> Then I see 0x8C8D8E8F twice (i.e. 0x88898A8B and 0x8C8D8E8F), then
>>>>> 0x9C9D9E9F (i.o. 0x90919293), 0x94959697 (OK), 0x9C9D9E9F (i.o
>>>>> 0x98999A9B), 0x9C9D9E9F (OK), 0xBCBDBEBF...
>>>>>
>>>>> Then I made a linker command file (.cmd) just to avoid the 0x20
>>>>> offset.
>>>>> ----------------first line below----------
>>>>> MEMORY
>>>>> {
>>>>> L2SRAM : o = 00000000h l = 00030000h
>>>>> EXTERNAL: o = 80000000h l = 01000000h
>>>>> }
>>>>>
>>>>> SECTIONS
>>>>> {
>>>>> .text > L2SRAM
>>>>> }
>>>>> ----------------last line above----------
>>>>> and I tried to reload (each time I do this I fill memory with 0 to
>>>>> exactly see what happens).
>>>>> The dump is in the following
>>>>> -- C6713 DSK/TMS320C6713 --
>>>>> 0x00000000 0x04050607 0x0C0D0E0F
>>>>> 0x00000008 0x0C0D0E0F 0x1C1D1E1F
>>>>> 0x00000010 0x14151617 0x1C1D1E1F
>>>>> 0x00000018 0x1C1D1E1F 0x3C3D3E3F
>>>>> 0x00000020 0x24252627 0x2C2D2E2F
>>>>> 0x00000028 0x2C2D2E2F 0x3C3D3E3F
>>>>> 0x00000030 0x34353637 0x3C3D3E3F
>>>>> 0x00000038 0x3C3D3E3F 0x7C7D7E7F
>>>>> 0x00000040 0x44454647 0x4C4D4E4F
>>>>> 0x00000048 0x4C4D4E4F 0x5C5D5E5F
>>>>> 0x00000050 0x54555657 0x5C5D5E5F
>>>>> 0x00000058 0x5C5D5E5F 0x7C7D7E7F
>>>>> 0x00000060 0x64656667 0x6C6D6E6F
>>>>> 0x00000068 0x6C6D6E6F 0x7C7D7E7F
>>>>> 0x00000070 0x74757677 0x7C7D7E7F
>>>>> 0x00000078 0x7C7D7E7F 0xFCFDFEFF
>>>>> 0x00000080 0x84858687 0x8C8D8E8F
>>>>> 0x00000088 0x8C8D8E8F 0x9C9D9E9F
>>>>> 0x00000090 0x94959697 0x9C9D9E9F
>>>>> 0x00000098 0x9C9D9E9F 0xBCBDBEBF
>>>>> 0x000000A0 0xA4A5A6A7 0xACADAEAF
>>>>> 0x000000A8 0xACADAEAF 0xBCBDBEBF
>>>>> 0x000000B0 0xB4B5B6B7 0xBCBDBEBF
>>>>> 0x000000B8 0xBCBDBEBF 0xFCFDFEFF
>>>>> -- Copyright © 2011 Texas Instruments -- Page 1 of 1
>>>>> Again, the first word is missing. I see some rule in data messing :
>>>>> 0x000000X0 0xX4x5X6X7 repeated every 0x10, data is
>>>>> + 4,
>>>>> I never see word 0xX0X1X2X3
>>>>> 0x000000X4 0xXCXDXEXF repeated every 0x10, data is
>>>>> + 8, word 0xX4X5X6X7 is at addr-4
>>>>> 0x000000X8 0xXCXDXEXF repeated every 0x10, data is
>>>>> + 4,
>>>>> I never see word 0xX8X9XAXB
>>>>> (similar to addr 0x000000X0)
>>>>> 0x000000XC 0xXCXDXEXF repeated every 0x10, data is OK
>>>>>
>>>>> Now the good news. [at least for some people] :-)
>>>>> Even if I thought there was something bad with the latching of the
>>>>> address, I tried again re-building in little endian (and obviously
>>>>> restoring the DSK to little endian via switch SW3-1).
>>>>> It works. Obviously I see data in LE, I mean if I dump words I see
>>>>> 0x03020100 and not 0x00010203, but this is what I was expecting as
>>>>> the
>>>>> asm source uses bytes.
>>>>> I've modified the asm file to use the entire (0x00030000) IRAM and
>>>>> it's OK.
>>>>> ----------------mod line below----------
>>>>> mystart:
>>>>> ; .asg 4,CNT ;size of outer loop (256 x 4 = 1KB)
>>>>> .asg 768,CNT ;size of outer loop (entire IRAM, 256
>>>>> x 768 = 0x00030000)
>>>>> ----------------mod line above----------
>>>>> Then I tried also in external memory by modifying the linker command
>>>>> file (.text > EXTERNAL) and it's OK.
>>>>> Now I've unleashed the emulator to it's full speed via CCS
setup
>>>>> (selected "Fixed with user specified faster value" for JTAG TCLK
>>>>> freq.
>>>>> and set "6.0MHz" in Enter a value... field). Yet another OK. Load
>>>>> time
>>>>> for the 192KB block in both IRAM and ext SDRAM is about 22 sec (I
>>>>> suppose the bottleneck is data xfer via JTAG not the target memory)
>>>>> versus the 25-26 sec I have with the default 1MHz TCLK. Not a big
>>>>> improvement for a x6 TCLK (as far as memory loading is concerned).
>>>>
>>>> More expensive emulators use hardware to manage the JTAG state machine
>>>> and 'other stuff'. The XDS100 does this in software and that
is
>>>> probably more of the bottleneck than the JTAG clock rate.
>>>>> Regarding memory filling via CCS, I noticed the beginning of the fill
>>>>> phase in IRAM has about the same speed as with 1MHz, but at a certain
>>>>> point... the filling lifts off (the blu advancement blocks in the
>>>>> popup go to the the end in about one second). May be I didn't
notice
>>>>> this at 1 MHz (the speed for filling the ext SDRAM seems quite the
>>>>> same, no lift off).
>>>>
>>>> Things like fill memory are 'blocked up' and are one of the
things
>>>> that
>>>> the 'scanloop' option uses to improve performance. It will be
slower
>>>> with that option disabled.
>>>>>
>>>>> Now the bad news.
>>>>> I do not consider the problem completely solved, as my board is big
>>>>> endian. I will check with the HW guy but I think that's fixed. In
any
>>>>> case the setting of the external peripherals should be modified in
>>>>> order to deal with the reversed endianity : not all the SW is
>>>>> endianity-aware (it shouldn't cost you so much if this is taken
into
>>>>> account from the beginning... by all the SW developers...
>>>>> Mike, may be I'm wrong, but I suppose the 'JTAG clock edge'
can be
>>>>> considered OK.
>>>>
>>>> With a simple and cleanly designed scan chain, testing has shown that
>>>> higher reliable scan rates can be attained by using the rising edge of
>>>> the JTAG clock as opposed to the falling edge as defined by the JTAG
>>>> standard. It is always safe to use the JTAG standard setting -
>>>> especially when we are not trying to push the speed limits. Now that I
>>>> think about, I do not know if they gave you the option on the XDS100.
>>>>> But what about endianity ?
>>>>
>>>> endianness
>>>> I believe that when connecting through the DSK USB port you are
>>>> using a
>>>> SD driver and when you connect with XDS100, you are using a TI driver.
>>>> It sounds like a sw problem. If I remember correctly-
>>>> DSK w/on board USB emulator, big endian - works
>>>> DSK w/on board USB emulator, little endian - works
>>>> DSK w/external USB emulator, big endian - works
>>>> DSK w/external USB emulator, little endian - works
>>>> DSK w/XDS100 emulator, big endian - does not work
>>>> DSK w/XDS100 emulator, little endian - works
>>>> Do the above accurately reflect the current state??
>>>>
>>>>> I remember Processor Properties for the simulator includes Endianness
>>>>> setting, but this is not available/needed for most of the cases. As
>>>>> example with the DSK USB Emulator I do work with both endianity
>>>>> setting with no problem : just set SW3-1 as you want and choose the
>>>>> related Endianness setting for the Compiler Build Option (it's
under
>>>>> the Advanced tab).
>>>>> Only the "6713 DSK Diagnostics Utility v3.1" program needs little
>>>>> endian setting (it fails in big endian).
>>>>>
>>>>>
>>>>> Thank you very much.
>>>>> Paolo
>>>>>
>>>>> ----- Original Message -----
>>>>> *From:* mikedunn
>>>>> *To:* Proware (tin.it)
>>>>> *Cc:* c6x
>>>>> *Sent:* Saturday, October 29, 2011 12:46 AM
>>>>> *Subject:* Re: R: Re: [c6x] Re: Programming TMS320C6713B
>>>>>
>>>>> Paolo,
>>>>>
>>>>> On 10/28/2011 2:48 AM, Proware (tin.it) wrote:
>>>>>> Thank you Mike,
>>>>>> I was waiting for the problems to be solved before posting the
>>>>>> result to the group in order to avoid intermediate steps.
>>>>>
>>>>> sometimes the journey is more interesting than the destination
>>>>> :-) [at least for some people]
>>>>>> Real filename is TIXDS100usb_Connection.xml, and as you said
>>>>>> it's
>>>>>> the only XDS100 connection file. I've modified it following
your
>>>>>> suggestion and I've renamed the original adding ".ori" at the
>>>>>> end.
>>>>>> I'm able to connect with the target. My feeling is that
it's a
>>>>>> little bit harder than before, sometimes I have to push the
>>>>>> reset
>>>>>> button and try a couple of times before succeeding (but may be
>>>>>> it's just my feeling).
>>>>>> I'm also able to set/check memory with no apparent problem.
>>>>>> Now when I try to load the .out file I have problems as soon as
>>>>>> CCS tries to load .cinit, that in my case is at 0x155F8
>>>>>> (int.RAM). I see the memory address 0 (.boot_load section) going
>>>>>> blank (0x00000000) and then filled with something, but the 2nd
>>>>>> section shown on the Loading Program popup, that is .cinit,
>>>>>> fails
>>>>>> at its first address (Error: File Loader popup window with "Data
>>>>>> verification failed at address 0x155F8. Please verify target
>>>>>> memory and memory map").
>>>>>
>>>>> Maybe we are finding out why TI did not support the 6713. If you
>>>>> want to, you can try the test below to get a better read on what
>>>>> is going on. Also, you may want to try setting the 'JTAG clock
>>>>> edge' to the JTAG std instead of TI's opposite setting.
>>>>>
>>>>> I have included the text for an asm file below. It does not
>>>>> execute, but I use it for troubleshooting 'load' problems.
Just
>>>>> create a new project and add only the file below to it [you can
>>>>> call it something like 'test.asm']. 'Compile' the
file like you
>>>>> would a C file - the compiler will figure it out. You will get 1
>>>>> warning - No Entry Point Defined [or something like that], just
>>>>> ignore it. If you look under project options, you should find one
>>>>> that will generate a listing file [.lst]. You do not need it, but
>>>>> it will show the assembly code. The memory contents will be the
>>>>> same as the 8 lower bits of the address. With a deterministic
>>>>> pattern, it is easier to assess what is going on. Just load the
>>>>> 'out' file and look at memory beginning at 0. I do not
remember -
>>>>> you might have to create a linker cmd file that loads the .text
>>>>> into address 0.
>>>>> ----------------first line below----------
>>>>> .global mystart
>>>>> .sect ".text"
>>>>>
>>>>>
>>>>> bitinc .macro
>>>>> .asg 256,CNT ;size of inner loop, loop counter
>>>>> .loop CNT
>>>>> .byte 256-CNT ;subtract remaining loop count
>>>>> and
>>>>> store as byte
>>>>> .eval CNT - 1, CNT ; update loop count
>>>>> .endloop
>>>>> .endm
>>>>>
>>>>> ;code start
>>>>> mystart:
>>>>> .asg 4,CNT ;size of outer loop
>>>>> .loop CNT
>>>>> bitinc ; inner loop macro
>>>>> .eval CNT - 1, CNT ; update loop count
>>>>> .endloop
>>>>> the_end:
>>>>> ;code end
>>>>> ----------------last line above----------
>>>>>> I tried to run xdsprobe. I've never used it before, it seems
>>>>>> it's
>>>>>> more XDS510/XDS560-oriented, anyway the command/output I
>>>>>> give/have are in the following :
>>>>>>
>>>>>>
>>>>>> /C:\CCStudio_v3.3\cc\bin> xdsprobe -f BrdDat/ccBrd0.dat -r -v/
>>>>>
>>>>> '-r' doesn't really do anything but a JTAG reset.
Try
>>>>> replacing it
>>>>> with '-i'.
>>>>>> //
>>>>>> /-----[Print the reset-command software
>>>>>> log-file]-----------------------------/
>>>>>> //
>>>>>> /This utility has selected an XDS510 class product.
>>>>>> This utility will load the adapter 'jioserdesusb.dll'.
>>>>>> This utility will operate on port address '0'.
>>>>>> The controller does not use a programmable FPGA.
>>>>>> The emulator adapter is named 'jioserdesusb.dll'.
>>>>>> The emulator adapter is titled '(null)'.
>>>>>> The emulator adapter is version '(null)'.
>>>>>> The emulator adapter is using 'Normal-Mode'.
>>>>>> The controller has a version number of '4' (0x0004).
>>>>>> The controller has an insertion length of '0' (0x0000).
>>>>>> The cable+pod has a version number of '0' (0x0000).
>>>>>> The cable+pod has a capability number of '0' (0x0000).
>>>>>> The local memory has a base address of '0' (0x000000).
>>>>>> The local memory has a word capacity of '1048576'
(0x100000).
>>>>>> This utility will now attempt to reset the controller.
>>>>>> This utility has successfully reset the controller./
>>>>>> //
>>>>>> /-----[Print the reset-command hardware
>>>>>> log-file]-----------------------------/
>>>>>> //
>>>>>> /The bridge library used to access the controller
>>>>>> and adapter does not read their log-files./
>>>>>> //
>>>>>> /C:\CCStudio_v3.3\cc\bin>/
>>>>>>
>>>>>> I will send you two pictures with the dump of address 0 (DSK vs.
>>>>>> XDS100).
>>>>>> You will notice content is similar (but not identical). I see
>>>>>> something wrong in the addresses.
>>>>>> Instruction 02000029 (MVK.S1 0x0000,A4) is at 0x0000000C for
>>>>>> DSK but it's at 0x00000008 for the XDS100 (for this last
I've
>>>>>> subsequently loaded symbols to try to match the DSK picture).
>>>>>> It's a mistery to me how this could happen in internal
memory...
>>>>>
>>>>> The problem is unrelated to internal memory. It is writing
'what
>>>>> the JTAG logic told it to write'.
>>>>>> By the way, where have you learned all this emu-porting-related
>>>>>> stuff ?
>>>>>
>>>>> I worked for TI on emulation software for the C6000 family
>>>>> devices.
>>>>>
>>>>> mikedunn
>>>>>>
>>>>>> Again, again and again, thank you in advance,
>>>>>> Paolo
>>>>>>
>>> ------- End of Original Message -------
>
_____________________________________
