CCE FAQ

From Texas Instruments Embedded Processors Wiki

Jump to: navigation, search
Translate this page to   

Contents


Where can I download the free CCE Core Edition?

The free CCE Core Edition IDE for MSP430 is available for download at www.ti.com/cce.

What is the difference between the free Core Edition and the Professional edition?

Other than the limitation to 16KB of compiled code, there is no difference between the Pro and Core Editions.

What is new in CCE v3?

Invoking Hex converter utility in CCE.

CCE hex converter utility supports the following output file formats:

The hex conversion utility can be invoked in the following three ways:

  1. (Recommended) Use CCE built-in Post build step to generate the hex file.  Please refer Section 2.1.5 "How to Generate Binary-Format Files (TI-TXT and INTEL-HEX)" of the Flash Emulation Tool User Guide (SLAU157) for more information of Hex Conversion utility.  Post-build step can be configured to generate the file automatically after every build by selecting predefined formats such as TI-TXT and INTEL-HEX in the "Apply Predefined Step" pulldown menu (Project >> Properties >> C/C++ Build >> Build Steps >> Post-Build Step). The generated file is stored in the <Workspace>\<Project>\Debug\ directory.
  2. By specifying the options and file names on the command line.  The following example converts the file test.out into TI-Tagged format, producing an output file, test.hex.
    >> hex430 -t test -o test.hex
  3. By specify the options and file names in a batch file. 
    You can create a batch file that stores command line options and file names for invoking the hex conversion utility. The following example invokes the utility using a command file called hexutil.cmd:
    >> hex430 hexutil.cmd

How to use printf in CCE v3?

Please refer to How to use printf in CCE

What is the difference between CCEssentials and Code Composer Studio™ (CCStudio)?

Code Composer Studio is developed specifically for Digital Signal Processor (DSP) applications and is based on proprietary software. CCEssentials is optimized for MSP430 16-bit MCUs with all the essential elements and is based on the industry standard Eclipse open source platform.

How to determine code size of program/how to create a Map file in CCE v3?

Please refer How to generate Map file in CCE

General tips to trouble shoot common debugger communication errors with CCE

The steps to troubleshoot some known issues related to debugger communication error:

  1. Check that the connection port is given as LPT1 or USB in the project debug properties.
  2. Be sure that you have selected correct target and command file in the project properties.
  3. In case you have Norton Internet security loaded and enabled, the problem could be fixed by first going into the security settings of the Internet Explorer and enabling a Java module that was disabled. Then, uninstall and reinstall CCE and when Norton internet security asks if the gdb should be enabled to connect to the internet, you should not choose the default which is to block it, but should choose to enable it.
  4. Please ensure that the FET drivers are installed correctly. Please refer to the Flash Emulation Tool (FET) Users Guide (slau 157) for information on software and hardware installation for USB and PP FET. 
  5. In case of USB FET, Go to my My Computer >> Properties >> Hardware >> Device Manager and confirm that the USB FET hardware is installed correctly. Right click and check in the properties whether it is installed correctly otherwise reinstall.

How do I create a new project using CCE v3?

Please refer to Media:New_Project_Using_Code_Composer_Essentials_V3.pdf

How to resolve the linker error with CCE v3?

While building the project in CIv3 if you come across the following linker error: "Fatal error: file "./ActionItem.obj" specifies large data memory model, which is not compatible with small data memory model specified in a previous file or on the command line"

Please follow the steps outlined below to resolve the error:

1. Please make sure that you have set a correct 'type' of MSP430 device i.e. Project Properties  C/C++ Build  Tool Settings  MSP430 Compiler v3.0  Runtime Model Options Silicon version (--silicon version) = mspx 2. Please make sure that you selected one of the large data model libraries Project  Properties  C/C++ Build  Tool Settings  MSP430 Linker v3.0  File Search Path Include library file or command file as input (--library) = rts430xl.lib OR rts430xl_eh.lib

You can find the libraries in the following path:

C:\Program Files\Texas Instruments\CCE v3\tools\compiler\MSP430\lib

How to resolve symbol referencing errors with fet_410_ta_01.c the timer example of MSP430x412/3 while linking?

Please note that MSP430x412/3 device has only one timer i.e Timer_A.

The devices MSP430xF415 and F417 have two Timers A3 and A5. For these devices one needs to include the respective header files (i.e. msp430x415/7.h) where you will find that the register symbols have changed slightly in order to distinguish between the Timer_A3 and Timer_A5. All the register symbols for Timer_A3 start with “TA0…” and all the register symbols for Timer_A5 start with“TA1…”. Looking at the msp430x415.h file, there are alternate names for the Timer_A 3 registers defined so that the TA0CCR0 can be also referenced as CCR0as it is done in the examples.

Unfortunately, this naming convention has not been taken care of in the linker command files in CCE.

There you will only find symbols defined as TA0… and hence the error messages during linking the project.

In order to run these examples you may want to modify symbol name for the Timer_A3 registers in the F415.cmd file to:

Timer0_A3

TAIV = 0x012E;
TACTL = 0x0160;
TACCTL0 = 0x0162;
TACCTL1 = 0x0164;
TACCTL2 = 0x0166;
TAR = 0x0170;
TACCR0 = 0x0172;
TACCR1 = 0x0174;
TACCR2 = 0x0176;


After doing the above changes the timer examples will build correctly with CCE 3.0.

How do I change the contents of RAM using Code Composer Essentials?

From the Memory Watch Window any RAM location can be changed while the debugger is paused. Simply enter the hex value for the address and then change the RAM value in the window. You will need to place the cursor immediately before the value in RAM and use the number keys on your keyboard to change the value. Do NOT highlight/select the value in the Memory Watch Window.

How can I program the MSP430 flash? What are the tools and options available?

1. Through the JTAG interface
2. Through the Bootstrap Loader

  1. Through JTAG, the following possibilities of programming the Flash exist:
    1. MSP430 Flash Emulation Tool Interface Board MSP-FETP430IF
    2. TI Serial Programming Adapter MSP-PRGS430
    3. TI Gang Programmer MSP-GANG430 Programmer from third parties: www.msp430.com - Click on `Development Tools`, Third Party Network` and then on `Third Party Hardware Tools – A number of third party companies are listed.
  2. Through Bootstrap Loader
  • TI recommends the tools listed on the third party web page, e.g. FlashPro430 programmer from third parties such as Elprotronic

Features of the two different programming methods:

  • You can blow the security fuse.
  • Blowing security fuse is supported by MSP-PRGS430, MSP-GANG430 and Third Party Gang Programmers.
  • It’s impossible to get any JTAG access or re-program a device through JTAG with a blown security fuse.
  • It’s impossible to blow the security fuse.
  • You can read, erase and re-program a device Flash with a blown security fuse. The
  • function is password protected. The password is the content of the interrupt vector table.


Some pointers on when to use which tool:

  • For program development. Works with TI- Code Composer Essentials (CCE) IDE, or IAR Embedded **Workbench development tool. Unable to blow the security fuse.
  • Writes the contents of a file to the MSP430 Flash. Reads the contents of a MSP430 Flash and stores it in a file. Can blow the security fuse, however it is not possible to write to the Flash of a device with a blown security fuse.
  • Writes the contents of a file to the MSP430 Flash. Reads the contents of a MSP430 Flash and **stores it in a file. Unable to blow the security fuse. Can write to the Flash of a device with a blown security fuse. This function is password protected. The password you need is the contents of the interrupt vector table.
  • Writes the contents of a file to the MSP430 Flash. Reads the contents of a MSP430 Flash and stores it in a file. Can blow the security fuse. It is not possible to write to the Flash of a device with a blown security fuse.
  • The RS-232 command set for the MSP-GANG430 and the BSL-Tools is documented in: MSP430 Gang **Programmer User’s Guide` (slau101k) and `Features of the MSP430 BSL` (slaa089d).

Does CCE v3 support 64-bit Windows Vista?

No, as on today CCE v3 does not support any 64-bit OS such as Windows Vista. Of course, it does support 32-bit Vista.

How to resolve the error “JVM Terminated Exit code =1”?

There are two options available to resolve this issue.

  1. Renaming a particular dll file from the system/system32 folders
  2. Steps followed to uninstalling and installing CCE

Renaming a particular dll file from the system/system32 folders

This error is related to a particular dll file. Usually a file named xerces-c_2_5_0.dll is located in the system or system32 of the Windows directory. To fix the above error, please rename or delete the above mentioned .dll file.

Essentially xerces is used for parsing XML. The CCE register definitions are XML as well. The problem with Xerces is that there are different versions like xerces-c_2_5_0 that are linked with different libraries. So if the one in system32 folder is linked with the wrong libraries then it creates a problem.

Because of this most applications will put the version of xerces that works with their app in the local installation folder somewhere. We put a version in: CIv 3\Debug Server\bin\win32 but for some people it seems to still pick up one from system32.

How do I fully uninstall and re-install CCE

Please refer to Uninstalling and installing CCE.

Header Files in CCE v3?

In the CCE include files (such as msp430x16x.h), the CCE v2 old-style interrupt vector defines are commented out using "//" instead of "/* */". If users select strict ANSI-C parsing to build the project, the "//" style comments cause errors, so they have to switch to "relaxed ANSI-C" parsing.

Extended Memory Usage Details

There are two ways that the compilers support the extended address space: small/large code and small / large data models.

In both cases, small and large refers to the ability to handle code or data values in only < 64K (small) vs in < 64K as well as > 64K address ranges (large).

A compiler’s support for the extended memory model refers to support for the set of 'extended memory' instructions that allow you to handle 20-bit pointers - which do so by adding extension word(s) to each instruction that account for the 'extra' 4-bits in the operand addresses.

The handling of these 20-bit pointers is a little different for code vs data memory because in a large code model, the compiler is concerned only with fetching instructions or branching to locations in memory addresses greater than 64KB. This requires the compiler to handle a relatively small subset of the extended memory instructions in very straightforward use cases (e.g.- CALLA, RETA vs CALL, RET).

For a large data model, the compiler must be able to handle data pointers in upper 64K (every pointer is now represented with 20-bits instead of 16-bits) as well as know when to use the appropriate MSP430X instructions to manipulate the 20-bit values, which is a much larger effort from the code generation side. A large data model also adds a certain amount of overhead - due to the extension words - that can be avoided if data access in the upper 64KB of memory were not required. IAR and CCE both support all large & small data models for the MSP430. Support for the large code model is inherent for all CPU devices (else, the upper 64K would not be able to be used!).

Packed Struct in CCE v3

Recent versions of some, but not all, TI compilers support "packed" struct types in GCC mode.

For non-packed structures, there is way to cause the compiler to align them to anything less than the "natural" alignment.

The members of a "struct" are laid out in order. All members are aligned to the appropriate alignment of its type. If necessary, padding is added before members to reach the correct alignment. Padding is also added to the end of the structure to round it out to a multiple of the strictest alignment of any of its members. The structure also inherits the alignment requirement of that member.

Profile clock in CCE v3

The profile clock counts processor instruction cycles or other events during run and single step operations when profiling. The profile clock is visible on the Code Composer status bar. Please note that the profile clock is used in Debug perspective only.

Instruction cycles are measured differently, depending on which device driver you are using. For device drivers that communicate through the JTAG scan path, instruction cycles are counted using the on-chip analysis capabilities of the processors. Other device drivers may require the use of other types of timers. To manage these resources, you must enable and disable the profile clock.

The simulator uses the simulated on-chip analysis interface to gather profile data. When the clock is enabled, the debugger takes over the necessary resources to implement instruction cycle counting. When it is disabled, the resources are available to you.

How to use profile clock in CCE v3?

Please refer to Profile Clock in CCE V3.

Clock setting:

How to use printf() library function for custom UART HW driver in CCE v3?

Please follow the steps mentioned below to use the printf() function.

  1. Extract the .zip file “<CCE_directory>/tools/compiler/MSP430/lib/rt src.zip” into a folder on your hard drive.
  2. Add the files fputc.c and fputs.c in the extracted /SHARED/ directory to your CCE project. fputc( ) is called for the characters in the printf( ) function . fputs( ) is called for the '%x' strings in the printf function.
  3. Edit the fputc and fputs functions to fit your needs (e.g.- poll TXIFG and load transmit buffer). Your printf function is now ported.
  4. Check the project settings so that the linker will not return any errors (i.e. - "xxx has been predefined in yyy ..." ):
    - Change the Command line pattern to be: ${command} ${inputs} ${flags} ${output_flag} ${output}
    - Placing ${inputs} before ${flags} puts the object files before the runtime library on the link command line, thus resolving the reference to the definition in the object file. Now rebuilding the project should no longer generate the symbol-redefined errors.
    Project >> Properties >> C/C++ Build >> MSP430 Linker.
  5. Increase the heap size to ~500 bytes under the menu option: Project >> Properties >> C/C++ Build >> Tool Settings >> Runtime environment.

Is it possible to work with CCE v2 and Cygwin simultaneously?

Since CCE v2 and Cygwin make use of the same DLLs, launching both the applications will result in DLLs with same names being opened. Windows will optimize out the DLLs with duplicate names, hence it is not possible to work with them simultaneously, however, if you are using exactly the same versions of the shared Cygwin libraries it is possible to run both CCE v2 and Cygwin at the same time. You cannot have different versions of the Cygwin libraries loaded.

CCE v3 Debugger/USB FET - is it possible to directly program/burn the fuse with one program file?

There is a stand alone utility that will load a program and then burn the fuse. Check for the following DSS script :

  1. Extract the script to <install>\DebugServer\scripting\examples\
  2. Modify the script to point to the program you want to load
  3. Create a target setup file from eclipse:
    • Right click on an existing project and select Properties
    • Select TI Debug Settings
    • Select the Setup tab and click Export
    • Save the file as <install>\DebugServer\bin\win32\SystemSetup.xml
  4. Run the program from the command line using the command "rhino LoadAndBurnFuse.js"

Note: Recommended to install CCE V3 SR2.

Download LoadAndBurnFuse code attachment

Assigning an address for a variable/constant in CCE - how would the following code "__no_init volatile int tempOffset @ 0x10F4" convert from IAR to CCE?

The variable can be assigned to absolute addresses or named sections using CCE.

To achieve absolute data placement, this can be done by adding entries to the linker command file and declaring the variable as extern in the C code. Please refer to section C.3 of MSP-FET430 Users Guide (SLAU157) for more details.

For named section you can place the variable in a named section using #pragma DATA_SECTION and then place the named section to a memory region within the SECTIONS directive of the linker command file. For eg:

In C code: 

#pragma DATA_SECTION(tempOffset, "mysect")
int tempOffset;

In the linker command file: 

MEMORY
{
   ...
   FLASH1 : origin = 0x10F4, length = 0x20
   ...
   ...
}
SECTIONS
{
   ...
   mysect : {} > FLASH1
   ...
}


Modifying the C startup routines to perform application specific initialization prior to calling main() in CCE v3

The C runtime library included with CCE contains a _system_pre_init routine where you can add any application specific initializations. This routine is called in the C startup routine (_c_int00() in boot.c) and provides a mechanism for the user to add application specific initialization prior to calling main(). This routine can be found in the file pre_init.c which is in C:\Program Files\Texas Instruments\CC Essentials v3\tools\compiler\MSP430\lib.

After making modifications to this file, you can add the modified file to your project. To ensure that the linker picks up your modified file rather than the skeletal file from the runtime library, you also need to do the following change to the project settings in CCE v3:

Project Properties->C/C++ Build->MSP430 Linker: Change the Command line pattern to be:
${command} ${inputs} ${flags} ${output_flag} ${output}

Placing ${inputs} before ${flags} puts the object files before the runtime library on the link command line, thus resolving the reference to the definition in your custom object file and not pulling in the definition from the runtime library. If you do not make this modification, you will get "symbol redefined" errors.

This modification to the project command line will only be required in CCE v3.0. In v3.1 the default project setting has been updated so this modification is not required.

No devices listed in the Device Selection page of the CCE v3 New Project wizard

This is most likely due to the CCE installation being corrupt or incomplete installation. To resolve the error, please uninstall and reinstall CCE using the attached steps.

What does the CCE linker error: 'placement fails for object "xxx"' mean and how to fix it?

The error 'placement fails for object "xxx"' refers to a section "xxx" which was unable to be placed into the memory region specified in the linker command file, most likely because the section size is larger than the length of memory region.

For example, if linker command file contains this: 

SECTIONS
{
 ...
 ...
 .int09   : {} > INT09
 ...
}

and the linker error says: 

"../lnk_msp430f1611.cmd", line 324: error: placement fails for object ".int09"

it means that the linker was unable to place the section ".int09" into the memory region INT09. The length of memory region INT09 in this linker command file is 0x2 so if the section is larger than that, the linker will generate this error.

Note: placement failures within the ".intX" sections may be the result of multiple defined interrupt handlers for the same interrupt vector table entry. Searching for #pragma vector = *_VECTOR across your project (including any libraries used) may turn up an existing handler which you should use to call your handler code instead of creating a new handler.

The best way to check the size of a section is to generate a link map file. To do this, go to Project Properties->C/C++ Build->Linker general options->Produce listing of input and output sections in <file> (--map_file) and specify the path and file name for a map file. Rebuild the project and view the map file. It should list the origin and length of all the sections. Here you can verify if the size of the .int09 section is larger than 0x2, and if so, the section allocation in the linker command file should be modified to avoid the error.

Pragma differences between CCE and IAR.

The pragma Directives for CCE are provided in the documentation SLAU132C and for IAR in the documentation EW430_CompilerReference. These documents can be found in your CCE_Install_Dir\docs and in IAR_Install_Dir\430\doc respectively.

Here are the supported pragmas for CCE and IAR:

CCE IAR
BIS_IE1_INTERRUPT Basic_template_matching , include_alias
CODE_SECTION bis_nmi_ie1 , inline
DATA_ALIGN bitfields , language
DATA_SECTION constseg , location
FUNC_EXT_CALLED data_alignment , message
FUNC_IS_PURE dataseg , no_epilogue
FUNC_NEVER_RETURNS diag_default , no_epilogue
FUNC_NO_GLOBAL_ASG diag_error , object_attribute
INTERRUPT diag_remark , optimize
NO_HOOKS diag_suppress , pack
Vector required , rtmodel
segment , type_attribute
vector


How do I force the CCE compiler to generate an error for missing function prototypes?

The C standard does not require a compiler to produce an error when a function is missing prototype however it is always advisable to have a prototype as it may otherwise produce unexpected results.

In CCE, the recommendation is to use the following compiler options to identify such missing prototypes:
Under Project Properties->C/C++ Build->Compiler->Parser Diagnostic Options:
Enable check boxes for --issue_remarks and --display_error_number

Now when you rebuild the project, you should see the remark: 

remark #225-D: function declared implicitly

whereever there is a call to a function that does not have a prototype

You can also set this remark to always be an error or warning so you don't overlook it. To do this, set the option:
"Treat diagnostic <id> as error" or "Treat diagnostic <id> as warning" and add the diagnostic id 225.

Please refer to the MSP430 Compiler Users Guide, http://www-s.ti.com/sc/techlit/slau132, for more details on these options.

Also note that the compiler will allow you to prototype a function differently (with different parameter types) in different C files, and no remark is generated for this by default. Since the compiler only has visibility into a single C source file at a time, it can only match the prototype found in that file with function calls in that file. For this reason, it is advisable to have such prototypes in a header file which is then included into all source files to avoid multiple prototypes of the same function.

What could cause interrupts to reset the device or jump to incorrect addresses when using extended memory?

In CCE v3 interrupt code needs to be placed in lower Flash memory for interrupt to function correctly. If it is not in lower Flash memory, unexpected resets/hangs may occur. The reason for this is that interrupt vectors have only 16 bits available hence only the lower 16 bits of these addresses are saved as interrupt vector. If the interrupt routine is in upper Flash memory, only the lower 16 bits of the address is taken and the device jumps to the wrong address.

The compiler tools in CCE v3 do not force the interrupt routines into low memory. So when code exceeds 64k the linker is free to allocate to upper Flash.

If you are running into unexpected resets/hangs, you can confirm if this is the cause of your issue by generating a link map file and looking at whether the code (.text) sections for the interrupt functions are being placed in upper Flash memory.

If so, a CODE_SECTION pragma can be used to force the routine into low memory, such as: 

#pragma CODE_SECTION(ADC12_ISR, ".text:_isr")    /* for C code */

or 

#pragma CODE_SECTION(".text:_isr")               /* for C++ code */

This pragma needs to be added to all interrupt routines to ensure they all get allocated to lower Flash.

In CCS v4 this modification is not necessary as the tools will automatically take care of it.

Why do Inline assembly statements that compiled with IAR give error "Illegal mnemonic specified" with CCE?

The TI assembler expects the first character of an assembly statement to either be a label or blank, (ie) the mnemonic cannot appear in the first column. Please refer to the MSP430 Assembly Lanaguage Tools Users Guide, Pg 41, for more information, http://www-s.ti.com/sc/techlit/SLAU131

For example, the code: 

void Delay_1us(void)
{
asm("MOV.W #0001h,R10");
asm("L1:  NOP");
asm("DEC R10");
asm("JNZ L1");
}

generates "Illegal mnemonic specified" for the MOV.W, DEC and JNZ instructions.

The code should be rewritten as: 

void Delay_1us(void)
{
asm(" MOV.W #0001h,R10");
asm("L1: NOP");
asm(" DEC R10");
asm(" JNZ L1");
}
E2e.jpg For technical support on MSP430 please post your questions on The MSP430 Forum. Please post only comments about the article CCE FAQ here.
Hyperlink blue.png Links
ARM Microcontroller MCU ARM Processor Digital Media Processor Digital Signal Processing Microcontroller MCU Multi Core Processor
Ultra Low Power DSP 8 bit Microcontroller MCU 16 bit Microcontroller MCU 32 bit Microcontroller MCU

Retrieved from "http://processors.wiki.ti.com/index.php/CCE_FAQ"
Leave a Comment
Personal tools
Namespaces
Variants
Actions
Navigation
Print/export
Toolbox