Debug Handbook for CCS

This page is no longer maintained and is kept here for reference only! Please go to this link for the most current version.

Introduction

This document is intended to serve as a "handbook" for all things related to Code Composer Studio v6 Debug environment. The majority of this document is also applicable to CCSv5 and standard Eclipse. Any areas where there are differences will be noted. The document provides an overview of the CCS debug system and the debug process for a typical embedded software program. It describes the different settings and properties that can be customized for a debug session. This page is a companion to the Projects and Build Handbook for CCS page.

Debug Overview

This section provides an overview of the debug environment.

The process

The debugging process happens after the project is completely built by the assembler/compiler/linker and, if free of errors, a standalone executable file (.out, .hex, .axf, etc.) is generated - for details of these previous steps check section 3 of the Projects and Build Handbook for CCS page.

Debugging can also happen in a system that has code already loaded and running, typically on advanced stages of the product design or with a finished product. These two methods are fundamentally identical with only procedural differences that can be seen in the Launching Debugger section below.

The physical debugging setup is shown below, with the two main components involved during a debug session:

• The connection is the interface between the host PC that is running CCS and the platform where the code is supposed to be executed (a device or board). The connection can be either a XDS, ICDI or MSPFET JTAG debug probe connected to the host PC via USB, Ethernet or even the older PCI and LPT (line printer) ports (in CCSv5 the connection can also mean a software simulator). Throughout this document the connection will also be called simply the JTAG debugger.
• The Board or Device is the hardware that contains one or more devices required for the executable to run. Throughout this document it will be called simply the target.

This setup then allows the host PC to communicate with the target, load data and code, control the execution of the program loaded via breakpoints, watchpoints and step operations, as well as read data back to the host PC to be displayed in views such as Watch, Memory and Disassembly. Additional views are referenced in the Basic Debugging views section below.

The debugger is launched from within CCS and performs the steps below. The process is the same whether the code is being downloaded to RAM or Flash. For Flash based devices, the built-in flash programmer automatically handles the flashing process.

1. In a typical debug scenario, the CCS debugger reads the Target Configuration File, creates a Debug Configuration and uses the information in these two files to connect to the JTAG debugger and communicate to the device in the target.
2. Once this communication is established, the CCS debugger starts executing a series of hardware initialization commands from a GEL script (if one is configured in the Target Configuration File).
3. If loading an executable, the CCS debugger splits the information of the executable file:
   • The contents of both code and data sections are sent through JTAG and stored in the appropriate memory locations of the device/board. The placement of this code follows the directives on the Linker Command File.
   • The debug symbols are kept in the host PC to allow correlating the memory addresses of the device/board with the source code of the project.
4. The CCS debugger performs one last step: it automatically sets a breakpoint in the device memory address that corresponds to the function main() and runs the device until it breaks at it.

Note: These last two steps are optional and depend on the settings present inside the Debug Configuration.

CCS can also debug an OS-hosted executable, which requires a high level operating system running on the target device/board (embedded Linux is the most common). However, the process of creating a project, building and debugging is outside the scope of this document but references can be found in the section Linux debug references below.

Target Configuration Files

A target configuration is a file that contains all the information required to debug a project using a JTAG debugger.

The target configuration file is a plain text XML file that has a .ccxml extension and contains all the necessary information for a JTAG debug session: the type of JTAG debugger, the target board or device (or even multiple devices) and optionally contains a path to a GEL (General Extension Language) script, which is responsible for performing device and/or hardware initialization.

As shown above, the Target configuration file includes one or more connection XML files (one per each core and JTAG entity, but all of them tied to the chosen JTAG debugger) and either a Board XML file (which contains a Device XML file plus the GEL script for the board) or a Device XML file directly (which may or may not contain a GEL script). The Device XML file contains the internal JTAG structure of the device and can optionally include several Module XML files, which describe a device's peripheral registers.

Despite the complexity, there are two simple ways to create the target configuration file:
Automatically when creating or modifying the project properties: To create it, simply define this parameter in the drop-down menu Connection in the New Project Wizard or in the Project settings.

• The file is placed in a subdirectory named targetConfigs inside the project directory
• This method is very simple as it automatically assigns the correct device and set it as the Active target configuration for the project
• Also, several example projects already create this file automatically.

Manually using the Target Configuration Editor: The Target Configuration Editor is a GUI inside Code Composer Studio that allows creating and modifying Target configuration files by simply specifying the two components (Connection and Board or Device). It also allows specifying advanced information that allows configuring advanced aspects of the JTAG debugger, as well as creating configurations for complex devices (with multiple cores) and boards (with multiple devices in the same scan chain).

• The file can be placed in an arbitrary directory in the system. By default it is the subdirectory ti/CCSTargetConfigurations inside the user area
• This method allows creating configurations for more complex devices or boards, as shown at the Custom configurations page.
• The Target configuration editor can also be used to edit the file that is automatically created with the previous method.

To create the target configuration file manually, simply launch the Target Configuration Editor from one of the several places inside CCS:

• Menu File --> New --> Target Configuration File
• From the Target configurations view (menu View --> Target Configurations). Click on the new target configuration button .
• From the project itself by right-clicking on the project and selecting New --> Target Configuration File.

The steps to define the Connection and Board or Device can be found starting at step 2 of the page Debugging projects in CCS

Test Connection

Once the target configuration file is created and saved, you can use the Test Connection button to verify that the JTAG connection is working at the lowest level. This button will execute various low level JTAG tests on the configured device. If the button is grayed out, it means that either the target configuration file has not been saved or the connection type being used is not supported (such as non XDS based connections like MSP-FET430UIF). For the MSP-FET430UIF, an alternative to the Test Connection button is the Identify... button which is next to the connection under the CCS Project Properties->CCS General->Main

The short video below demonstrates the usage of the Test Connection button:

Test JTAG connection

Advanced target configuration options

The procedure above mostly covers the Basic tab of the Target Configuration editor, but other two tabs are also important:

• The tab Advanced allows configuring important parameters of the JTAG debugger (mode of operation, clock speed, special signaling, endianess, among others), the device's internal JTAG structures (addresses, ports, cores) and the addition/removal of GEL files.
  • One of the most common JTAG debugger settings is the clock speed. This is covered in detail in this quicktip video.
  • GEL files are automatically added to all board configurations and several devices, therefore only need to be added/modified if a specific demand is required. If such editing is required, check the Adding GEL files to a target configuration page.
  • Another important setting is the JTAG Mode of operation in both the XDS110 and XDS200 Debug Probes. This is covered at these XDS110 and XDS200 topics.
  • This tab also allows to manually specify a Board Data File. Although unusual, this setting is important under certain circumstances.
• The tab Source shows the XML code of the Target Configuration File with all references to the XML files mentioned at the start of this section.

Target Configuration files can be tagged as Active or Default. This tagging affects which configuration the Debug launch button will use. The Debug launch button will search for and use a target configuration file in the order below:

• Use the file that is part of the project (physically or linked) - specified as Active
• Use the file that is set as the Default in the Target Configurations view

One exception is if you have a Target configuration file opened in the editor and in focus. In this case, the Debug launch button uses it instead of the Default or Active Target configuration file. For details, check the Launching Debugger section.

• Active configuration is assigned per project
• Default configuration is set per workspace

Target Configuration view

The Target Configuration view will display all target configuration files associated to the workspace. Target configurations can be easily managed from this view, including renaming/opening/deleting configurations, setting a configuration as the "Default", linking a configuration to an existing project, and so on.

The short video below demonstrates the features listed above:

Target Configuration view

More information on Target Configurations is in the Target configurations training module

Debug configurations

A Debug Configuration is the way that standard Eclipse (and by extension, CCS) describes how to launch a program in Debug mode.

Eclipse FAQ about Launch configurations: What is a launch configuration?

Debug Configurations are unique for each workspace. A Debug configuration can be manually created by going to menu Run --> Debug Configurations, or it is automatically created when the debugger is launched. Debug configurations may be cached and reused for future sessions that use the same configuration.

The name and physical location of the debug configuration is determined by how the debugger is launched.

• If the debugger is launched automatically on a project (using Green Bug button), the Debug Configuraton has the same name as the project. Physically the files are located in the project subdirectory /.launches
• If the debugger is launched manually, the Debug configuration has the same name as the Target Configuration File. Physically the files are located in the workspace subdirectory .metadata/.plugins/org.eclipse.debug.core/.launches

Note: One of the advantages of directly editing the Debug Configuration is to automate tasks when loading code to complex devices that have multiple cores. The short video below shows this process:

Multicore debug made easy

You can also create and assign a different debug configuration for each build configuration of your project. This short video shows the process:

Customizing debug launch for different build configurations

The Debug Configuration contains various settings separated by the following tabs:

Main: configures the main options for the debugger

• Target Configuration: points to the Target Configuration File
• Initialization Script: (optional) points to a JavaScript that can be used to initialize the target, pass parameters, etc. This is useful if you wish to run a custom set of steps during debug launch. Check this quick tip video for more information on using an initialization script.
• JTAG entity checkboxes: allows selecting what JTAG elements (cores/CPUs, routers, DAPs, etc.) are shown in the Debug view of the debugger. By default only CPUs are selected.
• Synchronize the properties for all compatible CPUs and Use the same console for the CIO of all CPUs: These two options are applicable to targets with multiple cores. For example, if you wish to display console CIO of the different cores in different views, then uncheck the CIO check box.

Program:

• Device: a drop down selection of each of the JTAG elements (cores/CPUs, routers, DAPs, etc.), which affects the selections in all the options below
• Project and Program: used to select either the project in the current workspace or the executable file to be loaded to the JTAG element selected above.
• Loading options: affects how the executable selected previously will be loaded: either by transferring its data to the target and the symbols to the debugger or simply loading the latter.

Target:

• All the options in this tab are described in the section Debug Properties below.

Source and Common:

• All the options in this tab match the standard Eclipse options which are described in the online Eclipse help:

Using Run/Debug Configurations

Portable Debug configurations

Sometimes it is desirable to share project debug/launch configurations along with the project. In such cases, it is recommended to avoid absolute paths to help with "portability". While relative paths are not supported in debug/launch configurations, it is possible to avoid absolute paths with the use of some default variables to reference files related to the project. For details, check the wiki topic below:

Portable_target_and_debug_configurations

Debug Properties

There are many settings that define the debug properties, such as Program/Memory Loading Options, Auto run options and Flash settings, to name a few. This section describes the more commonly used debug settings.

These settings can be viewed and customized through

• Project Properties --> Debug (if target configuration file is part of the project) or
• Right-click on the target configuration file in Target Configurations view and select Properties

Note that if you are using the first option above, you need to have already specified a “Connection” in your Project Properties in order for the Debug Properties to be populated. If you do not explicitly have a “Connection” specified, it may use the “Default” target configuration file and show the Properties based on that which may be incorrect/not match up with your device, so make sure you have the correct “Connection” selected for your project.

Note: For multi-core devices, make sure the Device drop-down shows the relevant core, for example as shown below for Beaglebone:

These settings can also be accessed, when already in a debug session (and in the CCS Debug perspective), either by going to

• menu Run --> Debug Configurations, and going to the Target tab or
• menu Tools --> Debugger options and/or Tools --> On-Chip Flash

The Debug properties are displayed under several categories. Each category allows you to control certain settings related to that category. Most users will not need to modify the default settings. The default settings are optimally chosen based on the processor being debugged, hence they may vary slightly by processor. For example, the default settings for MSP430 may be different than those for F28x.

Program/Memory Load Options

This category defines settings related to program/memory loading, verification options, connection options, disabling interrupts and resetting/restarting target during load.

Program/Memory Load Options:

• Disable all breakpoints when loading a different program - enabled by default
• Halt at program termination (requires setting a breakpoint) - when enabled, sets a breakpoint at end of program to allow debugger to halt there
• Enable CIO function use (requires setting a breakpoint) - when enabled, allows CIO output in console
• Enable Semihosting (requires setting a breakpoint at SVC_Handler) - this is available only for certain devices (Cortex A/M). See the CCS Semihosting page for more information.

Verification Options :
The choices are Full, Fast or No verification. It defaults to either Full (MSP430) or Fast (most other devices)

Connection Options:
These settings control actions during target connect

Disable interrupts:
These settings control whether to disable or enable interrupts when stepping and/or running code

Reset the target on a program load or restart and Restart the target on a symbol load as well as program load:
These settings control reset/restart actions during progrom/symbol load

Auto Run and Launch Options

This category defines Realtime Options, Auto Run Options and Launch options.

Realtime Options:
You can control whether to halt the debugger before any debugger access (by default, this is disabled).
There are also options to enable realtime mode (only available on cores that support realtime mode). See the section "Real-time Mode" below for details.

Auto Run Options:
By default, this is set to run to 'main' on a program load or restart.

• This symbol can be set to any other C or assembly symbol desired.
• If leaving the symbol field empty and disabling all the checkboxes, the debugger will be halted at the code entry point (typically _c_int00 or the reset vector) when the executable is loaded
• If leaving the symbol field empty but leaving at least one of the checkboxes enabled, the debugger will run freely immediately after the code is loaded.

Launch Options:
These options control the actions taken automatically when the debugger is launched.

Misc/Other Options

This category defines OS Aware debug options (when doing OS Aware debugging) and other miscellaneous options.

Cortex Disassembly Style Options

This category is only applicable for Cortex M/R/A devices and sets the mode in which instructions are displayed in the CCS disassembly view.

C28x Disassembly Style Options

This category is only applicable for C28x devices and sets the mode for the CCS disassembly view.

Flash Settings

This category defines several flash memory related settings and operations, that are described in more detail in the Configuring Flash Settings in CCS section.

MSP430 Properties

This category is only applicable for MSP430 and sets memory download options and other options specific to MSP430.

Clock Control:
This allows you to control which clocks to stop upon emulation halt. You need to be connected to a device to see the list of available clock controls.

Launching Debugger

In CCS the debugger can be launched either manually or in a fully automated fashion, which speeds up the process for targets that sport single cores.

Automatic launch

To launch the debugger automatically, simply click on the debug button located in the toolbar near the top of the CCS screen.

This debug button performs several steps:

• Find what is the Default (per workspace) or Active (per project) target configuration
• Create a Debug Configuration file (or use one created by a previous session)
• Launch the debugger with the settings defined in this file
• Connect to the core compatible with the C project
• Load the code to the target (erasing flash if configured/necessary)
• Run and halt at main() (or not run at all depending on the settings of the Debug Configuration file)

Manual launch

Launching the debugger manually can be useful in many scenarios:

• If you don't have a CCS project or simply have an executable or binary file to be loaded to the target.
• It helps troubleshooting any JTAG connectivity issues.
• It is one of the only options to connect to targets that have multiple cores, and some of them are held in reset when the device is powered up.
• It is the only option if you don't want to load code to the target but want to simply debug code that was previously flashed. In this case the debug launch is usually followed by loading symbols.
• It can be useful to debug an ARM Cortex core by accessing its memory map directly via de Debug Access Port (DAP):

How to access memory using the DAP

To launch the debugger manually, two main options are available:

• Open the Target Configurations view (menu View --> Target Configurations), right-click on the desired Target Configuration File and select Launch selected configuration.
• Double-click on the desired Target Configuration file in the Target Configuration view to open it in the editor. Click on the Debug button while the Target Configuration File is in focus.

Note: After the debugger launches, connection can be established by right-clicking on the core and selecting Connect. Once the core finishes executing its initialization GEL script (if one is required), the code or symbols can be loaded by going to menu Run --> Load --> Load Program or Load symbols.

A brief video that shows this method is below:

Easily launch the debugger without a project

For a project-less debug session, CCS may sometimes not be able to locate the source files to do the source-disassembly correlation. In such cases, there are a couple of ways to tell the debugger where to look for sources. Please see the section "Debugging without a project" in the CCSv6 Tips and Tricks presentation.

Using a new Target Configuration for the first time

When you create a new target configuration and start a debug session, the debugger will parse all the ccxml file and all associated device and module xml files. As it does this, it will create a database of that information. This process can take some time depending on the target. Basically, multi-core devices that reference a lot of module xml files (many memory mapped registers defined in the Register view) will take the longest. This applies to many Keystone devices. Custom configurations that then have multiple of such devices on one board will exponentially add to the time. However, once that database is created, subsequent launches of that target configuration will simply use the existing database and subsequent launches will be faster. But note that if you modify the target configuration file, it will regenerate that database again. For multi-core targets, placing unused cores in "BYPASS" mode will exclude those cores from the parsing process, speeding up the time required to generate the database.

In summary, the first launch of a target configuration will always be slower compared to subsequent launches of the same target configuration (until the target configuration is modified).

Basic Debugging views

Once the debug process is started and CCS switches to the CCS Debug perspective, the views and menus visible will be tailored for debugging. A certain set of views are opened by default, but other views can be opened from the CCS menu View.

The most common debugging views are described in the following page:

Debugging projects in CCS

Although that page references CCSv5, the content is equally applicable to CCSv6.

Debugging Library code

When debugging your application, you may be halted (either intentionally or unintentionally ) within a routine in one of the libraries linked to your application.
In such cases, you may see a message in the editor view: "Can’t find a source file at..." or "No source available for..."
In most cases, there will also be "View Disassembly..." and "Locate File..." buttons.

The reason for the message is that the program is halted at a location where the debugger is unable to locate the corresponding source file. This is typical when halted within a library that was built outside of the main project.

This type of message can occur when halted within any library, including the C runtime library, BIOS libraries, driverlibs, or other custom libraries that you link into your project.

Some situations when the message will appear:

• if you Suspend your code and happen to be halted within a library routine
• if you set a breakpoint at a label inside a library routine and run to it
• if your code stops within a library routine for some unintended reason

The message itself is harmless and can be ignored. But if you wish to do source level debugging of the library code, you can tell the debugger the location of the source file by clicking on "Locate File..." and browsing to the directory where the source file resides (if you have access to it and know where it is). Libraries from TI such as the C runtime library, driverlibs within MSPWare, TivaWare etc. come with sources, so you can point the debugger to the source directory. If you do not have access to the source, you can still view and step through the disassembly code by clicking on "View Disassembly...".

Without the source file correlation, the debugger will also be unable to set breakpoints within a library routine from the editor view. For example, if you open a source file that is part of a library and try to set a breakpoint in it from the editor view before making the correlation between the debugger and source file, then the breakpoint will not be enabled. You can still set the breakpoint from the Breakpoints view by specifying the symbol name. Then when the program is halted at the breakpoint, you can click on the "Locate File..." button to tell the debugger where the source files are located. Once the association with the source is made, you should then be able to set future breakpoints from the editor view.

Besides the "Locate File..." button, there are a couple of other ways to tell the debugger where to look for sources that are not part of the project. Please see slides 53-58 of the CCSv6 Tips and Tricks presentation.

Debugging Optimized code

If you have optimization enabled in your project that will impact the debug experience. The higher the level of optimization the more it will degrade the ease of debugging.
Please see this article about tradeoff between debug and optimization: Debug_versus_Optimization_Tradeoff

Advanced Debugging

Beyond the basic capabilities of inspecting memory and registers, setting breakpoints etc., TI devices also include several advanced hardware debugging capabilities. These capabilities vary by processor family and include things like:

• Non-intrusive access to registers and memory
• Real-time mode which provides for the debugging of code that interacts with interrupts that must not be disabled. Real-time mode allows you to suspend background code at break events while continuing to execute time-critical interrupt service routines.
• Multi-core operations such as synchronous run, step, and halt. This includes cross-core triggering, which provides the ability to have one core trigger other cores to halt.

Check the Multi-core Debug page.

• Advanced Event Triggering (AET) (available on select devices), which allows a user to set watchpooints, and halt the CPU or trigger other events based on complex events or sequences such as invalid data or program memory accesses. It can non-intrusively measure performance and count system events (for example, cache events).
• Trace (available on select devices), which enables users to find previously “invisible” complex real-time bugs.

Real-time Debug

There are different levels of real-time debug supported by different devices. Please see the section Debug Capabilities by Device

Profiling

Profiling is a dynamic program analysis that can analyze program execution and show where your program is spending its time. Profiling can be achieved by instrumenting either the program source code or its binary executable form using a tool called the Profiler. There are a few different ways to profile with CCS. This training module provides an overview of the profiling options available in CCS and which devices/configurations (simulator/emulator) are supported for each method. Also see the section Debug Capabilities by Device for device specific support.

Trace

Trace is an advanced debugging capability that allows capturing code execution and system events in real-time. It is very useful to perform advanced debugging on embedded systems, as it expands the basic JTAG debugging by performing real-time data gathering of several aspects of the embedded processor.

There are different types of Trace available on TI devices. They are applicable to both Processors and Microcontrollers, and even within those categories the capabilities vary by device and require the use of specific emulators.

Processor Trace (C6000, Cortex A8/A9/A15, ARM9, Cortex R5)

The types of trace supported on Processor families are Core/Instruction Trace and System Trace.

Trace can capture and store all instructions executed by the CPU in real time (Core or Instruction Trace) and on certain devices, can capture system events in real time such as memory interface throughput (System Trace). Trace can detect things like race conditions between events, intermittent real-time glitches, crashes from stack overflows, runaway code and false interrupts without stopping the processor. Trace is a completely non-intrusive debug method that relies on a debug unit inside the processir so it does not interfere or change the application’s real-time behavior. Trace can also be used to fine-tune code performance and cache optimization of complex switch intensive multi-channel applications. Processor Trace supports the export of program, data, timing and selected processor and system events/interrupts. Processor Trace can be exported either to an XDS560 Trace external JTAG emulator, or on select devices, to an on chip buffer Embedded Trace Buffer (ETB).

The short video below discusses the different types of Processor Trace:

• Trace overview

Microcontroller Trace (Cortex M/Tiva)

The type of trace supported on Cortex M devices is Instrumentation Trace. The Instrumentation Trace Macrocell (ITM) block on ARM devices is a software driven trace source. The main uses are printf style debugging, tracing OS and applcication events and emitting diagnostic system information.

The short video below discusses ITM and its usage:

• Instrumentation Trace Module for Cortex M

Debug Capabilities by Device

MSP430

MSP430 devices include an on-chip debug module called Enhanced Emulation Module (EEM) which allow advanced debug features such as hardware breakpoints, watchpoints, range breakpoints, among others. The module provides different levels of debug features based on the specific device being used.

The references below explain the EEM module and provide tutorials for its usage.

• Application note detailing the Enhanced Emulation Module (EEM): Advanced Debugging using the Enhanced Emulation Module (EEM) with Code Composer Studio
• Wiki Article with video tutorial: MSP430 Advanced Debugging using CCSv5
• Training Module: Enhanced Emulation Module
• Youtube video of EEM module overview: EEM Overview

Real-time Debug: Real-time mode debugging is NOT supported on MSP430 devices.

C2000

Advanced Event Triggering: C28x devices have some AET capabilties such as hardware breakpoints, watchpoints, and counters, but they are limited by the number of on-chip analysis resources. See the below reference for more details.

• Wiki article: Hardware Breakpoints and Watchpoints for C28x in CCS

Real-time Debug: Real-time mode debugging on C28x enables programmers to:

• examine and modify contents of memory/register locations while CPU is running and executing code
• halt/debug application while allowing user specified time critical interrupts to be serviced without interference

On C28x this is enabled by ICEMaker hardware.

More details on stop mode and real-time mode execution can be found in the C28x CPU and Instruction Set Users Guide, section 7.4 titled “Execution Control Modes”.

• Using Real-time Debug (Training Module): Real-time Debug
• Real-time mode also enables connecting to and debugging a program already running in Flash.
  Please see this Youtube video: Using real-time mode to debug C2000 program in Flash

Profiler: There are a few methods you can use to profile code running on C28x devices. The page below explains these methods:

• Profiling (Wiki article): Profiling on C28x Targets

Trace: C28x devices do not have support for Trace.

However, the Cortex M3 on Concerto devices have the Instrumentation Trace Macrocell (ITM) block which is a software driven trace source. This can be used for printf style debugging, tracing OS and application events and emitting diagnostic system information. On Concerto, ITM data is exported off the chip via Trace Port rather than SerialWire Output (SWO) so it requires an XDS560v2 debug probe.

Although the hardware supports it, CCS 6.0.x and 6.1.x do not have tools support for TPIU ITM trace. We hope to add this support into the tools in a future CCS release.

Software Breakpoints in code loaded to Flash, run from RAM: Software breakpoints set in code regions that are loaded to Flash but run from RAM and enabled prior to loading code may not work as expected. The breakpoints will appear be set correctly in the RAM address but program will not halt when the code is run the first time after a load/reload. Please see the reference below for the reason behind this behavior and suggested workarounds:

• Wiki article: C2000 Breakpoints in code loaded to Flash and run from RAM

Cortex M3/M4/Tiva/MSP432

Cortex M/Tiva devices have support for hardware breakpoints, watchpoints, and counters.

• Wiki article: Watchpoints for Stellaris in CCS

Real-time Debug: There is limited support for real-time access, in that you can access/modify memory in real-time while the processor is running. This is enabled through the DAP (Debug Access Port) which is part of the ARM emulation logic. The DAP enables the debugger to access memory of the device without requiring the processor to be halted.

• Using Real-time Debug (Training Module): Real-time Debug

Trace: The Instrumentation Trace Macrocell (ITM) block on ARM devices is a software driven trace source. The main uses are printf style debugging, tracing OS and application events and emitting diagnostic system information. Instrumentation Trace data needs to be exported off the chip either via Trace Port or Serial Wire Output (SWO). This is dependent on hardware implementation on the device, debug connector header and debug probe/emulator.

As of CCSv6, ITM trace on Cortex M3/M4 is only supported with XDS200 emulators. For MSP432 and CCS 6.1.0 and higher, ITM trace also works with the built-in XDS110 emulator in the MSP432 Launchpads.

More details are in this wiki article:

• SWO Trace

Other ITM related links are shown below:

• Youtube video of ITM Trace Overview: ITM Trace Overview
• ITM Trace (Training module) on Tiva C: ITM Trace
• MSP432 Debugging Tools: Using Serial Wire Output with Code Composer Studio™ Hardware Trace Analyzer: App Note

Keystone architecture (C66x)

Trace: This family of devices supports both Core and System Trace, and its capabilities are described in detail in the application note below:

• KeyStone Architecture Debug and Trace User Guide

Configuring Flash Settings in CCS

CCS v5/v6 comes with an integrated On-Chip Flash Programmer. When you load a program it automatically determines which sections reside in internal flash and proceeds to program the flash for those sections.

You can view and control several flash memory related settings and operations. The options and operations available in this view are dependent on the targeted processor.

The view can be opened, when in the CCS Debug perspective, using the menu Tools --> On-Chip Flash. The settings can also be accessed from the CCS Edit perspective by going to Project Properties --> Debug --> Flash Settings, but certain operations can only be performed after connecting to the device.

If you wish to connect to the device prior to or even without loading a program, see the section Manual Launch on how to launch the debugger manually and then connect to device.

Cortex M3/M4/Tiva

The following settings/operations are supported for CortexM/Tiva devices:

• Flash Settings
  • Crystal frequency - Set to a default value but can be modified
  • Reset target during program load to Flash memory - Determines whether a system reset will be performed by default or not before program is loaded
• Program Load Settings - Sets the erase method and gives the option to perform blank check and calculate CRC32 on flash memory
• Erase - Defaults to erase entire flash. This can be modified to:
  • select erase "By Address Range" and then specify the start and end address of flash to erase, or
  • select "Necessary Pages Only", which will then erase only the flash regions to which the linker has allocated storage
• Blank Check - Defaults to perform blank check on entire flash. Can be set for specified address range
• CRC32 - Defaults to calculate CRC32 on entire flash. Can be set for specified address range
• User Register Programming - Allows programming the non-volatile User registers (USER_REG0 and USER_REG1)
• MAC Address Mode - Programs the User registers by specifying the MAC address to be written to the User registers.
• Debug Port Unlock - Allows the JTAG/SWD debug pins to be unlocked if you configure the pins as GPIOs or there is some other issue that causes the device to lock up, such as configuring the system clock out of specification.
• ICDI Firmware Update - Can be used to update the ICDI firmware for boards that use a TI USB device

For the last three settings, refer to the LMFlash Programmer Help for more information.

C2000

The following settings/operations are supported for F28x devices:

• Clock Configuration - This setting is used to calculate the System Frequency for Flash operations. For Piccolo devices, since there is an on-chip oscillator the Flash programmer always uses that source to program the device, so these fields will not be modifiable.
• Flash Program Setting - Determines how the debugger handles Program Load operations (Erase/Program/Verify/RAM Only).
• Erase Sector Selection - Specifies if entire flash is to be erased (default) or only certain sectors
• Code Security Password - Used to Program Password, Lock or Unlock the device. See the CCS Online Help or refer to the C2000 device Users Guide for more information on Code Security Module and how it works.
• Frequency Test - When the Start Frequency Test button is pressed, it will toggle the specified GPIO Register pin to confirm proper clock configuration; and requires you to monitor the specified GPIO Register pin with an oscilloscope. Frequency Testing leaves the target in a running state; to stop the Frequency test, press the End Frequency Test button.
• Depletion Recovery - Checks the device and looks for sectors that are in depletion and attempts to recover them.
• Checksum - The Calculate Checksum button calculates checksums for Flash memory and One Time Programmable (OTP) memory.

MSP430

For MSP430, the Flash download options are under menu Tools --> Debugger Options --> MSP430 Debugger Options.

This menu allows for a few other options, but the main settings related to Flash programming are under Download Options. The setting determines which memory ranges will be erased prior to downloading the program.

A use-case where the Erase and download necessary segments only (Differential Download) option can be used is when you wish to quickly load a program similar to what is already programmed on the target without having to reload the entire program. If this option is on during program load, it keeps track of the programs that are being loaded at each iteration, and compares the changes in the program from the previous iteration to the current iteration to determine the incremental changes and download only the changed sections. The use-case for this option is for developers that are developing a large application, and are making minor code changes between iterations during development/debug. This option will make it faster to load the application on to the target after minor changes.

This option should NOT be used to load two different programs (such as a bootloader program and application program), as it might erase the first program when loading the second program, and it will also slow down programming as it will try to compare two totally separate programs unnecessarily.

A use-case where the Replace written memory locations, retain unwritten memory locations option can be used is when loading multiple .out files that mostly reside in different sections of memory. If there is a section that overlaps (such as vector table), load the application whose vector table you want to keep last, so that those memory locations are replaced.

Note that in CCS 6.0.x and 6.1.x, there isn't an option to simply erase flash only without downloading program. This feature is planned to be implemented in a future CCS release. However, a separate mass erase functionality is supported in Uniflash v3.4 and higher.

One question that is often asked is whether the flash programmer supports generation of checksum. Unfortunately, for MSP430, there is no support for checksum generation in the CCS flash programmer. Please ask the question in the MSP forums as they may be able to suggest other tools that have this capability.

Standalone Flash Programmers

In addition to CCS, there are also several standalone flash programmers available for your Flash programming needs. These tools are summarized here:

Flash Programming Tools for Microcontrollers

Debugging FAQs

The page below has FAQs related to debugging with CCS.

CCSv6 FAQs

Linux Debug References

Just for reference follows below a collection of links to debugging Linux systems.

• Linux Debugging with CCS
• Linux Debug hands-on training module
• Sitara hands-on training module
• Linux Debug in CCSv5
• U-boot Debug in CCSv5