Why does C6701 EVM boot in an endless .memcpy loop under CCSv4.2.4 using Blackhawk 560m?

If you are not reaching main, you have done something fundamentally wrong in the build process.

Please start with an Hello, World example and build up from there. Whether you are using DSP/BIOS or not, you will want to start from the most basic example to prove out your build flow.

Regards,
RandyP

If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

Yes, I expect I missed a compile or link option. I looked at all of the ones offered, but did not spot any that would seem to apply.

I also considered it might be an attempt to use memcpy to fill cache.

The disassembly window shows that all of my code is there.

Here is the project build procedure that I used:

Firmware File Directory Tree

To make it easy to manage project files by versions, keep source code, libraries, projects, and workspaces in separate directories.  This will allow versions to be easily archived/documented just by using the directory names if the proper directory tree naming convention is used.

Version identification should be part of the directory pathname.

Abbreviations

1-L  =  single left mouse click

2-L  =  double left mouse click

1-R  =  single right mouse click

2-R  =  double right mouse click

Chronological order of directory creation:

D:\CCS Chip Support Library SPRC090 2006-04-05 v2_31_00_16

            \Include Files

            \Library Files 3x

D:\CCStudio_v4.2.4 Workspaces

            \Training

D:\CCStudio_v4.2.4 Projects

            \Training EVM6701 Timer

D:\CCS Source Code Files

            \Training EVM6701 Timer Project

Procedure to create a new code development project for the CodeComposer development PC:

First use Windows Explorer to create the top Workspaces directory if it does not already exist:

D:\CCStudio_v4.2.4 Workspacess

Invoke CodeComposerStudio (2-L clicks on icon)

In "Workspace Launcher" window, select (1-L click) Browse:

            In "Select Workspace Directory" window:

                        In "Select the workspace directory to use" window,

                 select (1-L click) "CCStudio_v4.2.4 Workspaces"

     Select (1-L click) “Make New Folder”      

     In the “Select the workspace       directory to use” window,

                 edit “New Folder” to “Training” followed by a CR

     1-L click on “OK”

            1-L click on “OK”

Wait for Code Composer Studio to create workspace

Note - .metadata directory is now created under “Training”

Result:

D:\CCStudio_v4.2.4 Workspaces\Training

Project cannot be inside the workspace directory!

Code Generation Tools version is 7.2.7

First use Windows Explorer to create the top Projects directory if it does not already exist:

D:\CCStudio_v4.2.4 Projects

Create a project by selecting (1-L click):  File -> New -> CCS Project in the “C/C++ - Code Composer    Studio” window

            In “New CCS Project” window:

                        First, set project directory path:

                 Uncheck “use default location” (ignore warning message that pops up)

                 1-L click on "Browse"

                 Browse to “CCStudio_v4.2.4 Projects”, select with 1-L click

                 Select (1-L click) “Make New Folder”

                 In “Select the location directory” window, edit "New Folder" name (by 1-R click, then 1-L                                          click on "Rename") to “Training EVM6701 Timer”, followed by a CR

                 1-L click on "Training EVM6701 Timer” to make it the active project directory folder

                 1-L click on “OK”

     Second, create project directory name

                 Enter (1-L click) in "Project Name" window (NO CR!!!):

                             Training EVM6701 Timer

                             1-L click on “Next”

                 Select "Project Type" of “C6000” (Debug & Release)

                 1-L click on “Next”

                 In “Additional Project Settings” window, just 1-L click on “Next”

                 In “Project Settings” window:

                             For "Device Variant", select : "Generic devices", and "Generic C67xx Device"

                             For "Device Endianness, select "little"

                             1-L click on “Finish”

                 Project directory "Training EVM6701 Timer" is now created and populated

Result:

D:\CCStudio_v4.2.4 Projects\ Training EVM6701 Timer

Create the source file directory using Windows Explorer

Result:

D:\CCS Source Code Files\Training EVM6701 Timer Project

Link source files folder “Training EVM6701 Timer Project” to project “Training EVM6701 Timer” as follows:

            Open CCS workspace for project

            Enter File -> New -> Folder, and select (1-L click) “Training EVM6701 Timer” as the Project folder

            1-L click on "Advanced", check “link to folder in file system”,

                        1-L click on "Browse",

                                    select (1-L click) “D:\CCS Source Code Files\Training EVM6701 Timer Project”

                        1-L click on "OK"

            1-L click on "Finish"

Create Target Configuration File using special TI emailed procedure as follows:

In main C/C++ Code Composer Studio" window:

            Select Target -> New Target Configuration”

            Enter filename: EVM6701.ccxml

            Uncheck “use shared location”

            1-L click on "Workspace"

            1-L click to select project “Training EVM6701 Timer”

            1-L click on "OK"

            1-L click on "Finish"

Ignore "Basic" window, 1-L click to select (at bottom) “Advanced” tab, then “New”, select in "filter selection   by" window “TMS320C67xx” with 1-L click

Select (1-L click) connection “Blackhawk USB560M Emulator, 20 pin JTAG Cable”,

             then select (1-L click) “Finish”

Select (1-L click) “Add”, then 1-L click on “CPUs”, then 1-L click on “C670x”, then 1-L click on “Finish, then 1-L click on “Save”

Create source files in directory which is linked to project:

Select File -> New File (1-L click),

            In "Look in" window, 1-L click on check mark to open

            Then 1-L click on "Data(D:)", then 1-L click on “CCS Source Code Files”, then 1-L click on "Open"

            Then 1-L click on “Training EVM6701 Timer Project”, then 1-L click on "Open"

Enter filename “timer.c”

Select (1-L click) Open (CCS creates file if it does not exist)

Before compiling for the first time, the specific chip parameter names, include files, and libraries must be specified. These directories are not linked like the source files but rather are specified as parameters to the compiler and linker:

            In the "C/C++ - Code Composer Studio" main window:

                        1-L click on the "C/C++ Projects" window tab

                        1-R click on the "Training EVM6701 Timer [Active - Debug]" line

                        Select (1-L click) "Build Properties…"

            Set the compiler parameters:

                        1-L click on "Tool Settings" tab

                        1-L click on "C6000 Compiler"

                        Set target processor (6701) parameters:

                                    1-L click on "Basic Options"

                                                In "Target Processor Version" window, enter "6701" without a CR

                                                            1-L click on "Apply"

                                    1-L click on "Predefined Symbols"

                                    1-L click on "Predefine NAME" 's green + (on the right side)

                                                enter “CHIP_6701"

                                    1-L click on "OK"

                                    1-L click on "Apply"

            Link in Chip Support Library:

                        1-L click on "Include Options"

                                    1-L click on green + to the right of “Add dir to #include search path” window

                                                Type in pathname “D:\CCS Chip Support Library SPRC090 2006-04-05

                                                            v2_31_00_16\Include Files” in the "Add directory path" window

                                                1-L click on "OK"

                                                1-L click on “Apply”

                                                1-L click on C6000 Linker -> "File Search Path"

                                                            1-L click on green + to the right of “Add <dir> to library search path” window

                                                                        Type in pathname "D:\CCS Chip Support Library SPRC090 2006-04-05

                                                                                    v2_31_00_16\Library Files 3x

                                                                        1-L click on “Apply”

            Set the _dCHIP_6701 parameter:

                        1-L click on "CCS Build" in upper left corner under "type filter text"

                        In the "Device Variant" line,

                                    1-L click on the first checkmark (for drop-down list)

                                                select (1-L click) "Generic devices"

                                    1-L click on the second checkmark (for drop-down list)

                                                select (1-L click) "Generic C67xx Device"

                        1-L click on "Apply"

                        In pop-up "Save Build Configuration Settings" window

                        1-L click on “OK” (saves configuration)

                        1-L click on “OK” (exits window and returns to main CCS window)

            To set the stack size (optional):

                        In the "C/C++ - Code Composer Studio" main window:

                                    1-L click on the "C/C++ Projects" window tab

                                    1-R click on the "Training EVM6701 Timer [Active - Debug]" line

                                    Select (1-L click) "Build Properties…" in the pop-up window

                                    1-L click on "Tool Settings" tab

                                    1-L click on "Basic Options" under "C6000 Linker"

                                    1-L click on "Set C system stacksize" window and enter the stack size "0x400" (NO CR!!!)

                                    1-L click on "Apply"

                                    1-L click on "OK"

Put a copy of D:\CCS Chip Support Library SPRC090 2006-04-05 v2_31_00_16\Library Files 3x\

            Csl6701.lib into the directory D:\CCS Source Code Files\Training EVM6701 Timer Project

            using Windows Explorer "Copy" procedure (this library file is needed by the CCS build process

            to be in this location)

Please start with an Hello, World example and build up from there. Whether you are using DSP/BIOS or not, you will want to start from the most basic example to prove out your build flow.

CCS includes project examples and there are Getting Started Guides on the TI Wiki Pages. If you have any problem getting the example project from CCSv4 to work, try starting from an empty non-BIOS project that includes the right RTS library and write your own Hello, World.

Where did you get your Training EVM6701 Timer example project? What version of CCS was it written for? You probably expected it to be a simple starting place like an Hello, World, but it did not work out that way.

Where did you get your step-by-step from?

Regards,
RandyP

This project started 3 years ago using the F2812 and proved it would work. Now we are going into production. It is man-rated and must be rad-hard so we switched to the C6701. SQA must verify that the code is bug-free (by test) and that the documented versions (rts, my code, TI libraries, etc) are indeed what is in the release (a clean install and compile must be witnessed by them). SYS/BIOS can not be used since most interrupts are forbidden (emergency shutdown is allowed).

The step-by-step procedure is one document I have to generate to enable anyone to reproduce the code.

All this will have to be updated when CCS 5.1 is delivered to us (any day now).

The Training EVM6701 Timer example project is for open discussions like this one. The EVM is for familarization with each compile & link parameter that must be set while the actual  board that we designed is built and tested.

The rts library selection is set to "automatic".  Is there a way to find out what CCS chose?

I did discover one major cause of this memcpy loop:  For the EVM to work with a JTAG (Blackhawk 560M), the Boot Mode pins must be set for (00101) boot process = none; memory map = map1; memory at address 0 = internal.  However, the production board has external MRAM from which to copy to memory location 0. I found that the C6000 Linker -> Runtime Environment ->Initializaton model was set to ROM when it should be RAM for EVM. However, when I changed it to RAM, I now get a build error "warning: creating output section ".cinit" without a SECTIONS specification".  Should this be done with a pragma or a build parameter?  What would be the parameters? It still goes into a .memcpy loop, but at a different place.

Did you get the Hello, World example to work?

Did it have a linker command file (.cmd extension) associated with it? If not, look in the compiler or library folders for an example, usually called something like lnk.cmd but always with a .cmd extension.

What is MRAM?

Go back to the ROM model.

A ".memcpy" loop does not make sense because "." is not valid for a program address; it is used to designate an assembly directive.

We will have your thread moved to the Compiler forum since it is not a question about the C6701 device but rather about the compiler/build tools. And they might have access or knowledge about the tools for these devices. They may want details on CCS and compiler versions, etc., but maybe those answers are already embedded in your posts.

Regards,
RandyP

My scratch PC has not made the move to our new building yet, so I can not try Hello, World yet. I only have our production unit operational (can not mix files on same PC).

The disassembly window shows ".text,    text,    memcpy:" (I misread the "," for "." that I reported earlier) above the lines of assembly code that are stuck in a loop which eventually (<5min) crashes (must reset EVM).  I can use the Reset and Go To Main to move to those sections of code, so it did get loaded.

The EVM only has RAM (on-chip and off-chip external). The Bootmode pins are set for no boot process, MAP 1, Internal memory at address 0.  So for the Blackhawk 560m to load my program by JTAG, I assumed a memory map of IPM = 0000 0000 to 0000 FFFF and IDM = 8000 0000 to 8000 FFFF. This would allow me to verify that my program will fit in the memory planned. The build parameter C/C++ Build -> Tool Settings -> C6000 Linker -> Runtime Environment -> Initialization model -> Link using RAM autoinitialization model was used.

Our custom board has just the 6701 chip and 64K bytes of MRAM (magnetic ram, which is nonvolatile read/write memory) for program (at location 0-FFFF, CE0, MAP 0) and 64K for R/W data ((at location 0100 0000 to 0100 FFFF, CE1) or (at  location 0200 0000 to 0200 FFFF, CE2)) using the EMIF. So the build parameter will then be changed to ROM autoinitialization. Thus there will have to be a boot DMA cycle to copy the program from MRAM to on-chip RAM at 0140 0000 to 0140 FFFF.

I tried a supplemental link command file with MEMORY and SECTIONS, but have not been successful (one build option seems to be for the entire link process, another just an add-on at the end). Maybe a GEL file?

Given that the bootmode pins determine the boot process memory map, I need to know (preferably by example) the best way (in terms of being documentable) as to how to specify  a map for the EVM and one for our board.

I could not find the (map) link commands actually used by the EVM project, just fragments. The RAM autoinitialization selection did generate: "WARNING: creating output section ".cinit" without a SECTIONS specification.  Could .cinit be the source of the memcpy loop?

Steven,

The real experts may be waiting for me to stop talking before they jump in. If any of them know the C6701 tools, please jump in with the answer before I ruin any of this.

Use the ROM model in both cases. You can read about it in the Assembly Language Tools Reference Guide, but it just means that the variables will be loaded from tables.

In our TI Wiki Pages is an archived copy of the IW6000 training class, at TMS320C6x1x DSP Integration Workshop. This is from back when it supported the C6713, which is at least more similar to the C6701 than anything I have used for many years. The labs and solutions are available, and those will include example linker command files. You need to have a linker command file specifying where .cinit goes. The workshop may also help you understand some of the other roadblocks you are running into.

Regards,
RandyP

With what I've seen so far, I don't think the compiler team will be able to help.  If device settings such as pin and memory settings make or break the issue, the compiler team doesn't have that sort of expertise.  In particular, I don't know what it means to set the EVM to "no boot process."  This issue is going to require analysis by someone who understands the EVM before the compiler team can provide meaningful help.

If you are stuck in an infinite loop in memcpy before reaching main, this is probably during boot-time initialization of C global variables.  You should be able to verify this by setting a breakpoint on _auto_init and one on main.  If this is not the call site for memcpy that is entering an infinite loop, you have something else in the boot sequence that I'm unfamiliar with.

Steven Comee said:

The rts library selection is set to "automatic".  Is there a way to find out what CCS chose?

Create a linker map file with the --map_file option.  In it, you can see from which library various object files are taken.  You should see a bunch of references to a single RTS library.

Steven Comee said:

I now get a build error "warning: creating output section ".cinit" without a SECTIONS specification".

This is the warning you get when the linker command file doesn't explicitly place a section in a particular place in memory.  .cinit contains the initialization data for C global variables, so it needs to go in some sort of non-volatile memory.  You should explicitly allocate the .cinit section with an entry in SECTIONS

Steven,

Sounds like we shall move back to the C67x forum for now. At least you did get a couple of really good points from Archaeologist, so it was worth it to come here for a short time.

Steven Comee said:

I tried a supplemental link command file with MEMORY and SECTIONS, but have not been successful (one build option seems to be for the entire link process, another just an add-on at the end). Maybe a GEL file?

Are you implying that you already have a linker command file and you tried adding another one? You could just add the .cinit line into the original, but it should also work to add a supplemental one. In your compiler tools folder under \lib, you will find an example lnk.cmd file; I usually dismiss it because it is not a good memory map for our newer DSP cores, but it is made for yours.

It is very curious that you do not get the warning when you use the ROM model. It should still create a .cinit section, so it should still generate the warning. I see the same here with an Hello, World example before I put in the default lnk.cmd file copied from \lib.

In my opinion, you have a choice of two easiest paths to success:

1. Get an example program running and build your application into it in steps so you can figure out where you went wrong.

2. Debug your code to figure out what the memcpy loop is doing wrong. The source address or the count could be wrong, but you would still need to figure out where they came from. CCS will let you step over the memcpy call, assuming it is called a lot of times before the failing call. And then CCS will let you step into memcpy the time that it is going to fail so you can watch what it is doing as it fails.

#1 would be a lot easier than #2. #2 would be a lot easier than trying to figure out the cause of the failure from the facts in this thread. It is always easiest to start from something that works and build to your application. So #1 is my recommendation. Hopefully your scratch computer has come in by now or you have found someplace to get one.

Regards,
RandyP

Sorry for the delay in responding - I spent yesterday reading the 600+ pages of the workshop document. The general background was interesting but not too helpful - for example, the 6701 has no L2 cache so it was confusing as to where one was talking about a chip with it or without it.

The ROM autoinitialization compile had no warnings, no errors. The breakpoint at main never triggered.

The RAM autoinitialization compile had just the .cinit warning. The breakpoint at main was triggered but the breakpoint at the next C line (a call to CSL_init()) was never reached.

Both compiles used the default settings and TI libraries and both resulted in a memcpy loop for several minutes until I got a "board not responding" error.

The EVM Technical Reference (SPRU305) is not on your website. I found a 12 year old CD that had it. It has the memory map for the EVM. How can I confirm that CCS 4.2.5 uses this map? The Workshop manual talks about a "Memory Section Manager", yet I can not find it. My biggest problem is determining what info is current and what is obsolete and should not be used.

I do not know where to look for the default link.cmd file that CCS generated. The link.cmd file I tried was intended as a supplement for my project only. I will look for your \lib file today.

The "no boot process" is described in "Boot Modes and Configuration Reference Guide" SPRU642. By changing the bootmode pins on the 6701, one changes how the chip boots up. I need one setting for JTAG to load RAM (MAP 1) , one setting to cause JTAG to write to MRAM (to load my program to it), and another one to then load the 6701 on-chip RAM from MRAM (MAP 0, CE0). Could the loader think it is flash, which has a specific procedure involving an erase cycle? It seems that RAM  autoinitialization is the correct bootmode to use for the JTAG to load to the on-chip RAM directly. The ROM mode involves a DMA transfer from ROM to RAM - not what the EVM has.  This is the area the problem resides in.  So what is the correct forum? Is the Linker (part of Assembler manual) covered in the compiler forum or is there a forum for the Assembler/Linker? Is the problem with CCS not having all the support options for the 6701 in its menus? Is an old manual .cmd file needed?

We are building a flash memory module for the EVM 80-pin expansion memory interface socket to see if the automactically included flash burner is active as discussed in the guides (it should not be used if booting from ram), but it will take several weeks/months.

I am not concerned about the actual program logic (register access etc) as my application has been running on an F2812 chip for 3 years. My concern is what is the correct  boot process for the 6701 for the EVM and custom card and does CCS generate it.

I could not find a link.cmd file for my project. "libc.a" seems to be used instead. I could not find any SECTIONS memory map assignments! Where are they?

The Linker output was in "TrainingEVM6701Timer.out" as follows:

******************************************************************************

TMS320C6x Linker PC v7.2.7

******************************************************************************

>> Linked Mon Jan 16 13:15:39 2012

OUTPUT FILE NAME: <TrainingEVM6701Timer.out>

ENTRY POINT SYMBOL: "_c_int00" address: 00000e00

MEMORY CONFIGURATION

name origin length used unused attr fill

---------------------- -------- --------- -------- -------- ---- --------

RAM 00000001 fffffffe 00001570 ffffea8e RWIX

SECTION ALLOCATION MAP

output attributes/

section page origin length input sections

-------- ---- ---------- ---------- ----------------

.pinit 0 00000004 00000000 UNINITIALIZED

.cinit 0 00000000 00000224 COPY SECTION

00000000 0000000c timer.obj (.cinit)

0000000c 00000004 --HOLE--

00000010 0000002c rts6700.lib : exit.obj (.cinit)

0000003c 00000004 --HOLE--

00000040 0000001c : _lock.obj (.cinit)

0000005c 00000004 --HOLE--

00000060 0000003c csl6701.lib : csl.obj (.cinit)

0000009c 00000004 --HOLE--

000000a0 0000012c : csl_irq.obj (.cinit)

000001cc 00000004 --HOLE--

000001d0 0000004c : csl_timer.obj (.cinit)

0000021c 00000004 --HOLE--

00000220 00000004 --HOLE-- [fill = 0]

.data 0 00000008 00000000 UNINITIALIZED

.text 0 00000020 00001000

00000020 00000240 rts6700.lib : memcpy62.obj (.text:_memcpy)

00000260 000001c0 csl6701.lib : csl_irq.obj (.text:_mux2Tables)

00000420 000001a0 timer.obj (.text)

000005c0 00000180 csl6701.lib : csl.obj (.text:__CSL_init)

00000740 00000160 rts6700.lib : autoinit.obj (.text:__auto_init)

000008a0 00000140 csl6701.lib : csl_timer.obj (.text:_TIMER_open)

000009e0 00000120 : csl_timer.obj (.text:_TIMER_reset)

00000b00 00000120 rts6700.lib : exit.obj (.text:_exit)

00000c20 000000c0 : cpy_tbl.obj (.text:_copy_in)

00000ce0 000000a0 csl6701.lib : csl_irq.obj (.text:__IRQ_init)

00000d80 00000080 : csl_timer.obj (.text:_TIMER_close)

00000e00 00000080 rts6700.lib : boot.obj (.text:_c_int00)

00000e80 00000060 csl6701.lib : csl_timer.obj (.text:_TIMER_configArgs)

00000ee0 00000040 : csl_timer.obj (.text:_TIMER_start)

00000f20 00000040 rts6700.lib : args_main.obj (.text:__args_main)

00000f60 00000020 csl6701.lib : csl.obj (.text:_CSL6701_LIB_)

00000f80 00000020 : csl_timer.obj (.text:_TIMER_getCount)

00000fa0 00000020 : csl_timer.obj (.text:_TIMER_pause)

00000fc0 00000020 rts6700.lib : _lock.obj (.text:__nop)

00000fe0 00000020 : exit.obj (.text:_abort)

00001000 00000020 csl6701.lib : csl_irq.obj (.text)

.stack 0 00001020 00000400 UNINITIALIZED

00001020 00000008 rts6700.lib : boot.obj (.stack)

00001028 000003f8 --HOLE--

.far 0 00001420 00000154 UNINITIALIZED

00001420 000000f4 csl6701.lib : csl_irq.obj (.far)

00001514 00000028 : csl.obj (.far)

0000153c 00000024 : csl_timer.obj (.far)

00001560 0000000c rts6700.lib : exit.obj (.far)

0000156c 00000008 : _lock.obj (.far)

.bss 0 00001578 0000001c UNINITIALIZED

00001578 0000001c timer.obj (.bss)

GLOBAL SYMBOLS: SORTED ALPHABETICALLY BY Name

address name

-------- ----

00001578 $bss

00001578 .bss

00000008 .data

00000020 .text

00000fe0 C$$EXIT

00000f60 _CSL6701_LIB_

0000158c _Loop_count

00000d80 _TIMER_close

00000e80 _TIMER_configArgs

00000f80 _TIMER_getCount

000008a0 _TIMER_open

00000fa0 _TIMER_pause

000009e0 _TIMER_reset

00000ee0 _TIMER_start

00001580 _Timer1_busy

00001584 _Timer1_count

00001588 _Timer1_count_old

0000157c _Timer1_delta

000005c0 __CSL_init

0000150c __IRQ_dispatchTable

00001448 __IRQ_eventTable

00001000 __IRQ_hookFetchPacket

00000ce0 __IRQ_init

000014cc __IRQ_intTable

00001420 __STACK_END

00000400 __STACK_SIZE

0000153c __TIMER_deviceTable

0000155c __TIMER_hBios

00001554 __TIMER_hDev0

00001558 __TIMER_hDev1

00000001 __TI_args_main

00001568 ___TI_enable_exit_profile_output

ffffffff ___TI_pprof_out_hndl

ffffffff ___TI_prof_data_size

ffffffff ___TI_prof_data_start

ffffffff ___binit__

00001578 ___bss__

ffffffff ___c_args__

ffffffff ___cinit__

00000008 ___data__

00000008 ___edata__

00001594 ___end__

00001020 ___etext__

ffffffff ___pinit__

00000020 ___text__

00000f20 __args_main

00000740 __auto_init

00001560 __cleanup_ptr

00001564 __dtors_ptr

0000156c __lock

00000fc0 __nop

00001020 __stack

00001570 __unlock

00000fe0 _abort

00000e00 _c_int00

00000c20 _copy_in

00000b00 _exit

00001578 _hTimer1

00000468 _main

00000020 _memcpy

ffffffff binit

ffffffff cinit

00000008 edata

00001594 end

00001020 etext

ffffffff pinit

GLOBAL SYMBOLS: SORTED BY Symbol Address

address name

-------- ----

00000001 __TI_args_main

00000008 .data

00000008 ___data__

00000008 ___edata__

00000008 edata

00000020 .text

00000020 ___text__

00000020 _memcpy

00000400 __STACK_SIZE

00000468 _main

000005c0 __CSL_init

00000740 __auto_init

000008a0 _TIMER_open

000009e0 _TIMER_reset

00000b00 _exit

00000c20 _copy_in

00000ce0 __IRQ_init

00000d80 _TIMER_close

00000e00 _c_int00

00000e80 _TIMER_configArgs

00000ee0 _TIMER_start

00000f20 __args_main

00000f60 _CSL6701_LIB_

00000f80 _TIMER_getCount

00000fa0 _TIMER_pause

00000fc0 __nop

00000fe0 C$$EXIT

00000fe0 _abort

00001000 __IRQ_hookFetchPacket

00001020 ___etext__

00001020 __stack

00001020 etext

00001420 __STACK_END

00001448 __IRQ_eventTable

000014cc __IRQ_intTable

0000150c __IRQ_dispatchTable

0000153c __TIMER_deviceTable

00001554 __TIMER_hDev0

00001558 __TIMER_hDev1

0000155c __TIMER_hBios

00001560 __cleanup_ptr

00001564 __dtors_ptr

00001568 ___TI_enable_exit_profile_output

0000156c __lock

00001570 __unlock

00001578 $bss

00001578 .bss

00001578 ___bss__

00001578 _hTimer1

0000157c _Timer1_delta

00001580 _Timer1_busy

00001584 _Timer1_count

00001588 _Timer1_count_old

0000158c _Loop_count

00001594 ___end__

00001594 end

ffffffff ___TI_pprof_out_hndl

ffffffff ___TI_prof_data_size

ffffffff ___TI_prof_data_start

ffffffff ___binit__

ffffffff ___c_args__

ffffffff ___cinit__

ffffffff ___pinit__

ffffffff binit

ffffffff cinit

ffffffff pinit

[66 symbols]

Steven,

libc.a is a generic placeholder that tells the compiler to pick the right library based on the other arguments you have specified. You can look through the .map file listing that you pasted above and see the .lib file that is actually used. If you prefer, you can use this in place of libc.a to explicitly select your rtsxxxx.lib file.

Do you explicitly specify your csl .lib file somewhere?

You are not using a linker command file, so you were never using a supplemental linker command file. Get the one from the \lib folder and use it. This will be the same folder where your rts .lib file resides. This file is where the SECTIONS commands are found.

Take a look at the .map file for the ROM model version. It has a .cinit section, too, right? But it is not a COPY_SECTION so I still do not understand the differences in the warnings. You luck out for it to be working; you do not want to be using the default case when there is no linker command file.

Steven Comee said:

I am not concerned about the actual program logic (register access etc) as my application has been running on an F2812 chip for 3 years. My concern is what is the correct  boot process for the 6701 for the EVM and custom card and does CCS generate it.

This raises concerns in my mind. Registers in the F2812 are different from registers in the C6701.

You are porting code from one platform to another, which may be easy but may have some subtle speedbumps along the way. The fact that you are running into initialization issues (memcpy) means that you do not have things working right. I have given you my advice, and will let others with more insight into your problem give you better help.

Regards,
RandyP

csl.lib is specified by using: active project 1-R click -> Build Properties... -> C/C++ Build -> Tool Settings -> C6000 Linker -> File Search Path -> add <dir> to library search path -> green + "D:\CCS Chip Support Library SPRC090 2006-04-05 v2_31_00_16\Library Files 3x"

Because of the erros it was generating, I deleted my link.cmd file (at D:\CCS Source Code Files\Training EVM6701 Timer Project\6701linkmap.cmd) from the box just above the one mentioned above (libc.a is still there).

BINGO - C:\Program Files\Texas Instruments\ccsv4\tools\compiler\C6000 Code Generation Tools 7.2.7\lib does NOT contain any link.cmd (nor any *.cmd) files, only the rts* files! Hence, no SECTIONS. Question is, where is it? In the Tool Settings -> C6000 Linker -> Linker Output window, what (if any) should be the settings for the five options?

The transfer from F2812 to C6701 is not exact. My application only uses the timer counter, a serial port, and some discretes. 70% of the C code can be transfered, the rest is (manually re-coded) converted to the 6701 environment (different registers).

There is a hello_lnk.cmd file at C:\Program Files\Texas Instruments\ccsv4\tools\compiler\C6000 Code Generation Tools 7.2.7\prelink\prelink_xip_segment.

It does not allocate .pinit

The question is, should it be referenced in:

 active project 1-R click -> Build Properties... -> C/C++ Build -> Tool Settings -> C6000 Linker -> File Search Path -> Include library file or command file as input -> green + -> "C:\Program Files\Texas Instruments\ccsv4\tools\compiler\C6000 Code Generation Tools 7.2.7\prelink\prelink_xip_segment\hello_lnk.cmd"

or

active project 1-R click -> Build Properties... -> CCS Build -> General -> Linker Command File -> "C:\Program Files\Texas Instruments\ccsv4\tools\compiler\C6000 Code Generation Tools 7.2.7\prelink\prelink_xip_segment\hello_lnk.cmd"

?

I tried putting hello_lnk.cmd in the CCS Build window. It generated

"../hello_lnk.cmd", line 24: warning: no matching section
"../hello_lnk.cmd", line 26: warning: no macthing section

I believe it is referring to .const and .fardata. Can you confirm it is safe to ignore these warnings? I'll try running it first thing tomorrow (If I stayed late and ran it now and it did not work, I wouldn't be able to sleep tonight!)

Steve, I am not sure if this will help or not.

Have you considered using CCS 3.3?  This is the final version prior to the migration to the eclipse architecture.

I have a working project in CCS3.3 for an C6701-SP EVM.    Unfortunately I cannot be of much help with the newer CCS.

If you have a license for CCS4+, then I believe that you can download CCS3.3 for use.    I found this note in a CCS product folder:

Effective 01 November 2011

• If you wish to purchase a license for CCStudio v3 Platinum, this product is no longer sold.
• However if you have purchased a license for the current CCStudio product (v4 or v5), you can request a download link to CCStudio v3 at: request_ccsv3@list.ti.com

Regards,

Wade

Actually, I had to go back to CCSv3.1 (CCStudio_v3.1\examples\sim62xx\code_coverage\select_func\c6211_c671x_device_lnk.cmd) to pull out this 1996 lnk.cmd file (I had a hard time remembering which floor tile to pull for the CD - to protect it from the lab neatness patrol):

/****************************************************************************/
/*  lnk.cmd   v4.30                                                        */
/*  Copyright (c) 1996-2002  Texas Instruments Incorporated                 */
/****************************************************************************/
-c
-heap  0x2000
-stack 0x4000

/* Memory Map 1 - the default */
MEMORY
{
        PMEM:   o = 00000020h   l = 0000ffe0h
        EXT0:   o = 80000000h   l = 400000h
        
}

/* Memory Map 0 */
/*
MEMORY
{
        EXT0:   o = 00000000h   l = 01000000h
        EXT1:   o = 01000000h   l = 00400000h
        PMEM:   o = 01400000h   l = 00010000h
        EXT2:   o = 02000000h   l = 01000000h
        EXT3:   o = 03000000h   l = 01000000h
        BMEM:   o = 80000000h   l = 00010000h
}
*/

SECTIONS
{
    .text       >       PMEM
    .stack      >       EXT0
    .bss        >       EXT0
    .cinit      >       EXT0
    .cio        >       EXT0
    .const      >       EXT0
    .data       >       EXT0
    .switch     >       EXT0
    .sysmem     >       EXT0
    .far        >       EXT0
}

The above file generates no warnings nor errors. My program runs correctly on the SECOND load - run, stop, breakpoints, memory watches all work. However, it stays in a memcpy loop upon the first load.

The file that generated the warnings is (C:\Program Files\Texas Instruments\ccsv4\tools\compiler\C6000 Code Generation Tools 7.2.7\prelink\prelnk_xip_segment):

/****************************************************************************/

/* lnk.cmd v4.00 */

/* Copyright (c) 1996-2000 Texas Instruments Incorporated */

/****************************************************************************/

-c

-heap 0x2000

-stack 0x6000 /* Modified by Gayathri on 6/3/2003 as Perennial P50031 fails

due to stack overflow - solution suggested by Todd Snider */

MEMORY

{

PMEM: o = 00000020h l = 01000000h

BMEM: o = 80000000h l = 01000000h

}

/* Added sections .neardata and .rodata to permit ELF testing. Doesn't */

/* affect COFF, since COFF doesn't have these sections. -Indira, 6/9/08 */

SECTIONS

{

big_ro:

{

*(.text)

*(.const)

*(.far)

*(.fardata)

} > PMEM

.stack > BMEM

.args > BMEM

GROUP

{

.neardata /* Move .bss after .neardata and .rodata. ELF allows */

.rodata /* uninitialized data to follow initialized data in a */

.bss /* single segment. This order facilitates a single */

/* segment for the near DP sections. */

}>BMEM

.cinit > BMEM

.cio > BMEM

.data > BMEM

.switch > BMEM

.sysmem > BMEM

.ppinfo > BMEM

.ppdata > BMEM, palign(32) /* Work-around kelvin bug */

}

My program runs correctly on the SECOND attempt with this file. Why?

In SPRU642 Boot Modes and Configuration Reference Guide page 8 is the memory map for the 6701. Pages 12-15 discuss the effect of the BOOTMODE cpu pins.

The problem seems to be with how .cinit and the hex6 address fixer work together with the JTAG load process to accommodate the BOOTMODE options. Apparently, the first JTAG load does not get handed off to execution correctly. In the second attempt, RAM is already loaded so execution handoff proceeds correctly.

Can you offer any more details (than what is in the manuals) on the CPU boot process? For example, how did you write .cinit and the JTAG boot?

Clicking on target -> Reset returns you to memory location 0. Clicking on run enters an infinite loop (memcpy).

Clicking on target -> Restart returns you to main. Clicking on run executes the program normally.

What is the bootloader (cinit) doing?

The use of .cinit is covered in the C6000 Optimizing Compiler User's Guide and in the workshop materials from the Wiki.

If you want to use Reset or Restart, you need to be using the ROM model.

Reset will correctly put the PC at 0 which is where a hardware reset would put you. Restart will artificially put the PC at the defined entry point for which there should be a branch at address 0, in other words, at address 0 there should be a reset interrupt "vector" which branches to the entry point which is usually _c_int00.

Maybe you don't have your vector table implemented or it is not implemented correctly. I think this is explained in the Assembly Language Tools Reference Guide and in the workshop materials from the Wiki.

Regards,
RandyP

If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

I found that the link file that you must use is dependent upon the bootmode pin settings.  The following file works for using JTAG to load into on-chip RAM (bootmode = 00101), no boot process):

/*******************************************************************/
/*  C6701_ramJTAG_lnk.cmd                                          */
/* Link command file to load a program into on-chip RAM using JTAG */
/* address & length in bytes                                       */
/*******************************************************************/
-c
-heap  0x0100
-stack 0x0400

/* Bootmode bits = 00101, no boot process */

/* Memory Map 1 (MAP 1) has on-chip internal program memory mapped at address 0 */
/*   IPM = internal program memory (ram)  */
/*   IDM = internal data memory (ram)  */

MEMORY
{
  IPM:  o = 00000020h  l = 0000FFE0h  /* MAP 1 - 64K but avoid interrupt vector table */
  IDM:  o = 80000000h  l = 00010000h  /* 64K */
}

SECTIONS
{
  .text   > IPM
  .stack  > IDM
  .bss    > IDM
  .cinit  > IDM
  .const  > IDM
  .data   > IDM
  .switch > IDM
  .sysmem > IDM
  .far    > IDM
}

My test program runs with no problems - breakpoints, watches all work as expected, no memcpy infinite loops - PROBLEM SOLVED.

BUT.... now for the final problem.  I wanted to put (asynchronous) MRAM 32-bit memory on the J6 port. Then I would use bootmode = 00010, no boot process. This would  use Memory Map 0 and put MRAM at address 0 using CE0 so that JTAG could then load it just like on-chip RAM. The link file that I would use is:

/*******************************************************************/
/*  C6701_mramJTAG_lnk.cmd                                         */
/* Link command file to load a program into MRAM using JTAG        */
/* address & length in bytes                                       */
/*******************************************************************/
-c
-heap  0x0100
-stack 0x0400

/* Bootmode bits = 00010, no boot process */

/* Memory Map 0 (MAP 0) has MRAM chip mapped at address 0 using CE0 */
/*   MPM = MRAM program memory         */
/*   IDM = internal data memory (ram)  */

MEMORY
{
  MPM:  o = 00000020h  l = 0000FFE0h  /* MAP 0 - 64K but avoid interrupt vector table */
  IDM:  o = 80000000h  l = 00010000h  /* 64K */
}

SECTIONS
{
  .text   > MPM
  .stack  > IDM
  .bss    > IDM
  .cinit  > IDM
  .const  > IDM
  .data   > IDM
  .switch > IDM
  .sysmem > IDM
}

Then I would change the Bootmode bits to 11101 (32-bit ROM with default timings boot process) and change the MRAM chip enable to CE1. The link file for this step would be:

/************************************************************************/
/*  C6701_romBoot_lnk.cmd                                               */
/* Link command file to load a program into on-chip RAM from ROM (MRAM) */
/* address & length in bytes                                            */
/************************************************************************/
-c
-heap  0x0100
-stack 0x0400

/* Bootmode bits = 11101, 32-bit ROM with default timings boot process */
/* CPU copies 64K bytes (in 32-bit groups) from memory at CE1
/*   to on-chip program memory starting address 0 */
/* MRAM must be on CE1 at address 01400000h to 0140FFFFh as asynchronous
/*   expansion memory */

/* Memory Map 1 (MAP 1) has on-chip internal program memory mapped at address 0 */
/*   IPM = internal program memory (ram)  */
/*   IDM = internal data memory (ram)  */
 

MEMORY
{
  IPM:  o = 00000020h  l = 0000FFE0h  /* MAP 1 - 64K but avoid interrupt vector table */
  IDM:  o = 80000000h  l = 00010000h  /* 64K */
}

SECTIONS
{
  .text   > IPM
  .stack  > IDM
  .bss    > IDM
  .cinit  > IDM
  .const  > IDM
  .data   > IDM
  .switch > IDM
  .sysmem > IDM
}

The middle step (MRAM burning) is the problem. Page 1-14 in SPRU305 shows that the 6701 EVM has SBSRAM (instead of asynchronous expansion memory) connected to CE0.  Thus I will have to build my own EVM or try a link file that uses the LOAD, RUN commands to load at 01000000 (CE1) but run at 0. Any thoughts?

Steve, it is good to see that you have made some progress.  Unfortunately, I am not code expert.

However, I we do have another EVM that was designed to uses the ceramic device in order to facilitate some radiation testing.

It has flash and sdram.   I do not know the form factors of you mram, so uncertain if this will help you.

See attached schematic.

Regards,

Wade

Thank you. The MRAM is a Honeywell 64-pin quad flatpack with 16 data lines, similar to your flash. The key question is: is your flash socketed? If not, how is it programmed onboard? As I worked thru the Bootmode CEx assignments by the C6701 internally, there would have to be a jumper for TCE0 and TCE1 to CE for MRAM to work.  Your board is much simpler than the C6701 EVM and might work as is if the flash can be programmed by the CCSv4/5 with a Blackhawk 560m.