Multi-Core Debug with CCSv4.x

Overview

CCStudio v4 supports debug of multi-cores targets.

Starting a Debug Session

There are several options for starting a debug session for a multi-core target:

• Launch TI Debugger (Target->Launch TI Debugger): This will launch a debug session for the target without any project association. The user can then choose which core(s) to load a program for
• Debug Active Project (Target->Debug Active Project): By default this will build the active project and then launch a debug session and load the application to the first compatible core. The default behavior of 'Debug Active Project; can be changed using the 'CCS Debug Settings' (right-click on the project and select 'Debug Properties...' and then the 'Debugger' tab):
  

  Fig. 1: CCS Debug Settings - Default
  • Prompt to select CPU will prompt the user to select which applicable core to load the application on when selecting 'Debug Active Project':
    

    Fig. 2: Prompt to Select CPU
  • Connect to exact CPU can be used to specify which core to load the application on when selecting 'Debug Active Project':
    

    Fig. 3: CCS Debug Settings - Connect to Exact CPU

Debug Context

The 'Debug' view displays the stack frames for each debug-able core on a multi-core target. Most of the various views in the Debug perspective (Register, Variables, Disassembly, Memory, etc) will reflect the context of the highlighted stack frame for the specified core. To switch the context to another core, simply highlight the stack frame for that other core in the 'Debug' view and the various views will be updated to reflect the context of that core.

Fig. 4: Debug View

Certain views, such as the 'Memory' view, allow you to "pin" the view to the context of the currently selected core. This can be done using the 'Pin to <core>' icon in the view, as long as this function is supported by the view. Doing this will allow you to change the debug context to another core but still have that view reflect the context of the core it was originally "pinned" to. An example use case would be to open up several instances of the 'Memory' view with each view tied (or "pinned") to a different core to allow side-by-side analysis of the current contents of memory for each core during debug.

Fig. 5: Pinning the Memory View to the Current Debug Context

Not all views support "pinning" to a core. With those views, it is not possible to have the context always reflect the same core when switching the overall debug context from core to core in the 'Debug' view. If it is strongly desired to be able to open multiple views of the same type and have then always reflect the context of a core, then another 'workbench window' can be created (see 'Using Multiple Workbench Windows' section below).

Current views that support "pinning":

• Memory
• Console
• Scripting Console
• MMU
• Cache

Debugger commands (run, step, reset, etc) will apply only to the selected core in the 'Debug' view.

Synchronous Mode

When the 'Enable Synchronous Mode' button in the 'Debug' view is enabled, debug commands will be sent to all cores. Any target execution command (run, step, halt, etc) will also become synchronous in behavior, if the device being used supports this mode. This will guarantee that stepping commands are executed simultaneously on all cores. If a particular device being used does not support HW assisted synchronous command execution, then the commands will be sent to each processor in a sequence. This may take several cycles between each processor receiving a run or halt command and will not result in synchronous execution of the cores.

Fig. 6: Enable Synchronous Stepping Mode

Grouping Cores

Custom Groups

Commands can be sent to a specific set of cores at the same time. This can be done by multi-selecting (or "grouping") the cores of interest in the 'Debug' view ('CTRL' key + left mouse click) to create a 'Custom Group' of cores. This is useful when you want to send a debug command to only some (but not all) cores. When multiple cores are "grouped" together, they will appear highlighted in the 'Debug' view and debug commands will be sent to all the cores that are part of the group. Note that commands are SENT to the cores and it does not guarantee that execution of the commands are carried out simultaneously. It is important to remember this for target execution commands (run, halt, step, etc) where such precise synchronous execution of commands may be desirable. In such cases, 'Synchronous Mode' may be enabled to ensure synchronous execution of the group (see 'Synchronous Mode' section above).

Fig. 7: Multi-selecting Cores

When multiple cores are grouped, the debug context of the various views will always switch to the first core listed in the 'Debug' view with the exception of views pinned to a particular debug context.

NOTE: After sending a debug action to the custom group, the group will be 'unselected'. Hence the group must be reselected to send another debug action to the same group of cores. To avoid this behavior when constantly working with groups, it is recommended to use 'Fixed Groups' instead (see below).

Fixed Groups

Once a debug session is started, the user may create a more permanent group by filtering out visible processors from Debug View. Hence when 'Synchronous Mode' is enabled, debug commands will be sent only to visible cores in 'Debug' view. Debug commands will be sent to all visible cores without the need to select them. The user may filter out cores in 'Debug' view by selecting desired cores and selecting 'Set Debug Scope' from context menu. Debug View filtering may be disabled by selecting 'Window->Scope->Reset Debug Scope'.

In the screenshot below, a 'Fixed Group' will be created for just the first and third core in the 'Debug' view by multi-selecting them and then using the 'Set Debug Scope' option:

Fig. 8: Creating a 'Fixed Group' via the 'Set Debug Scope' Option

Once the debug scope has been set, the second core is filtered out and only the first and third cores are visible:

Fig. 9: 'Fixed Group'

Using Multiple Workbench Windows

Multiple main windows (called workbench windows) can be created to have each window dedicated to a specified core during the debug session. A new window can be created using the 'Window->New Window' option. A workbench window has its own debug context (workbench window 1 can show data for core 1 while workbench window 2 shows data for core 2, etc). Note that creating a new window does not mean creating a new debug session. Each window will be associated with the same debug session but can be specified, using the 'Debug' view, to reflect the context of a different core. This is similar to the CCStudio 3.3 multi-core debug environment where a CCStudio control window can be opened for each core.

Fig. 10: Multiple Workbench Windows

The debug sessions for all cores are displayed in all workbench windows by default, but the user can filter the cores shown in each workbench widow (workbench window 1 can be set to shows only core 1, while workbench window 2 shows cores 2 and 3.) For more information on filtering cores, see the 'Fixed Group' section above.

Breakpoints

Grouping Breakpoints

The 'Breakpoint' view can display all breakpoints set for all cores and group them by cores. This can be enabled by selecting 'Group By->Debug Targets' in the options for the 'Breakpoint' view:

Fig. 11: 'Breakpoint' View Grouping Options

This will group breakpoints under their respective cores to easily identify which core a breakpoint if set for:

Fig. 12: 'Breakpoint' View Groups

The editor also differentiates which breakpoints are set for the core of the current debug context and which are not by displaying the icons for the breakpoints set for a different debug context to looked 'faded' versus breakpoints which are active for the current debug context:

Fig. 13: Breakpoints in the Editor

Global Breakpoints

TBD

Scripting Multiple Cores

Scripting console language may be used to automate repetitious tasks when working with multi-core device. e.g. A script may be written to start a debugger, open debug sessions only for desired cpus and then connect, load program and perform additional steps, such as setting a breakpoint and running to it. Script may also be constructed to create a menu in a GUI that will invoke this script, thus resulting in a single action bring up of a complex multi cpu device. Please see Scripting Console topic for further information. This link contains a script example of multi-core device bring up using a script.