1. Code Composer Studio v6 Fundamentals Workshop for MSP432

2. Agenda CCSv6 Overview Getting Started with CCS (with Lab)
Basic Debugging (with Lab)
Optimizer Assistant (with Lab)
Real-time Memory Debug (with Lab)
SWO Trace (with Lab)

4. CCSv6 Overview 4

5. Code Composer Studio What is Code Composer Studio?
Integrated development environment for TI’s embedded processors supporting all Microcontrollers and Processors in a single environment
A suite of tools including a debugger, compiler, editor…
Based on the Eclipse open source software framework
Eclipse is widely used by many development environments
Offers a rich set of code development tools
TI contributes changes directly to the open source community
Extended by TI to support device capabilities
Integrate additional tools & functionality
OS application development tools (TI-RTOS, Linux, Android…)
Code analysis, source control…

6. Where does CCS fit in the Ecosystem?
Run-Time Software
Development Tools
High-level OS support and TI-RTOS
OS Independent support and TI-Wares software packages
Code Composer Studio™ Integrated Development Environment (IDE) and other IDEs
Optimizing compilers
JTAG emulators & boards
Support & Community
TI Design Network: off-the-shelf software, tools and services
Forums & Wikis
In-person and online training
For those of you who are new to TI’s embedded software & tools ecosystem, it is an area that TI has invested heavily in over the years. The ecosystem is comprised of runtime software including real-time operating systems like TI-RTOS, embedded Linux and a multitude of software packages; there are Development Tools including the Code Composer Studio Integrated Development Environment, JTAG emulators, and development boards such as LaunchPads and evaluation modules. On top of this there is a rich community providng expertise, turn-key solutions, product support and training.

7. Getting Started View
Initial screen visible when Code Composer Studio is launched
Provides fast access to common tasks
Create a new project
Use a example
Open the App Center…
Embedded Getting Started Video walks users through the basics of using CCS
Links to support, videos and training material

8. CCS App Center Access to new products and features
Keep products up to date from within CCS
Further reduce CCS download size
Great way to promote features

9. Resource Explorer
Easily access a broad selection of packages such as controlSUITE, MSP430ware, TivaWare, TI-RTOS…
Guides you step by step through using examples
Provides links to documentation, videos and other collateral

10. Energia Support Import existing Energia sketches
Leverage existing work
You can build/edit/debug Energia projects inside CCS
Provide more debugging capabilities
JTAG debug
Register display
See the generated code
Keep it simple
CCS will most likely be customer’s second debugger ever used and their first full software development environment
Recommended to use “Simple” Mode

11. ULP (Ultra Low Power) Advisor Turning MCU developers into Ultra-Low-Power experts
ULP Advisor analyzes all C code line by line.
Checks against a thorough Ultra-Low- Power checklist.
Highlights areas of improvement within code.
Can benefit any application
Checks all code within a project at build time
Enabled by default
Parses code line-by-line
List of 15 Ultra-Low-Power best practices
Compilation of ULP tips & tricks from the well-known to the more obscure
Combines decades of Ultra-Low-power development experience
Identify key areas for improvement
Listed in the “Advice” view
Includes a link to more information

12. Optimizer Assistant
Provides advice on how to get the best performance for available code size
Graphical display of memory usage
CCS APPS

13. Serial Wire Output (SWO) Trace
Trace can be used for profiling hardware events and supported by CCS through a variety of common use-cases
Statistical Function Profiling
Data Variable Trace
Interrupt Profiling
Custom Core Trace
What is Serial Wire Output (SWO) Trace?
SWO Trace is an ARM debugging tool that is provided because the MSP432 has an ARM Cortex-M4 processor.
Not related to EnergyTrace+ in any way; only similarities are both use the PC for data, and they share the same COM port

14. EnergyTrace
Energy-based code analysis tool that measures and displays the application’s energy profile and helps to optimize it for ultra-low-power consumption
CCS APPS

15. GUI Composer: See & Control
Create GUI applications with GUI Composer that provide:
Visibility into what is happening in the target application
The ability to control target variables

16. Debug Server Scripting
Scripting interface that allows automated control of the debugger through a command-line script
Perfect for automating testing and performance benchmarking of your application
CCS GUI
Command line script
Scripting (DSS)
Debugger
Debug Server Scripting, or DSS for short, is basically a set of Java APIs into the CCS debug engine. It is possible to control most of the key functionality of the debugger by calling these APIs from a script or program. Because of this, DSS is an excellent utility to automate testing and benchmarking of applications normally run with the CCS debugger.
DSS can be used with a variety of languages, with the key requirement being the ability to be able to interface with Java APIs. Some languages that can be used with DSS are:
Javascript - which is the default language supported “out-of-the-box” by DSS
Perl – by using the inline::java perl module to allow Perl to call Java APIs
Python – by using Jython – a java implementation of Python
TCL – by using a java implementation of TCL such as Jacl
Basically, if the language can interface to Java APIs, it should be able to be used with DSS.
However we strongly encourage using standard javascript with DSS. This is because this is the official supported language of DSS, and the only language that will work right out-of-the-box with no additional software needed. All the examples that come with DSS are in javascript and additional out-of-the-box functionality like a script debugger is available if you use javascript.
All DSS examples shown in this webinar will be javascript examples. 16

17. PinMux
Configure pin multiplexing settings, resolving conflicts and specifying I/O cell characteristics through a graphical interface
Results are output as C header/code files that can be imported into your project

18. UniFlash
Stand-alone tool that provides a single interface for programming Flash memory and executing Flash based operations
Installed and used independent of CCS
Allows programming via multiple interfaces:
Graphical User Interface (GUI)
Scripting
Command line 18

19. XDS560v2 – High Performance
XDS Debug Probes
Entry level JTAG emulator
USB interface
IEEE modes with XDS100v3
3 models based on JTAG headers (14pin TI, 20pin TI, 20/10pin ARM)
$50-$100
Intended replacement for the older XDS100
USB interface
Supports SWD/SWO and Energy Trace+
Currently only available integrated on to LaunchPads/Kits (External standalone versions coming later this year)
Under $100
XDS100v2/v3 – Entry Level
XDS110 – Entry Level
Excellent balance of performance and cost
USB interface (Ethernet version available)
Supports SWD/SWO Trace
20pin TI, 14pin TI, 20pin ARM and 10pin ARM connectors
$295
USB or USB + Ethernet interfaces
Includes multiple JTAG adapters (14pin TI, 20pin TI, 20pin ARM, 60pin MIPI, some include 60pin TI)
System Trace (for supported devices)
$995 - $1495
XDS200 – Mid Range
XDS560v2 – High Performance

20. TI Cloud Tools
Create, edit, build, and debug your CCS projects on selected LaunchPads… all in the Cloud!
Supported cloud tools
Cloud IDE
Resource Explorer
PinMux
GUI Composer

21. Extensive Support Videos, Blogs, Forums Global customer support
E2E Community
Wiki
Videos, Blogs, Forums
Global customer support
Search for answers
Technical articles
Training
Design ideas
Wiki:
Same infrastructure as Wikipedia.
Wealth of technical articles
E2E Community:
Conversation oriented. You can post a question and get answers within a community. We have experts monitoring posts and answering questions.

22. YouTube Channel
YouTube Channel
Watch videos about the various features and capabilities of CCS

24. GETTING STARTED WITH CCSv6 AND MSP43224

25. MSP432P401R LaunchPad Setup Software: Hardware:
Code Composer Studio v6.1.3 or greater
With all MSP components installed
MSPWare 3.30 or greater
Hardware:
MSP432P401R LaunchPad
USB JTAG Connection

26. Lab Setup
Refer to the Lab Requirements and Setup section in your Lab Handbook for more details 26

28. Getting Started: Blink LED Example28

29. Getting Started: Exercise Summary
Key Objectives
Import and build the Blink LED example program using the Resource Explorer
Start a debug session and load/flash the program to the target
Run the program
Tools and Concepts Covered
Eclipse Concepts (Workspace, Workbench, Perspectives, Views, Projects)
Resource Explorer
Overview of the CCS Build and Debug System
Importing/Building/Running an example project/program 29

30. Workspace
Launching CCS for first time requires you to select a workspace folder
Defaults to your user folder 30

31. Eclipse Concept: Workspaces
Main working folder for CCS
Contains information to manage all the projects defined to it
The default location of any new projects created
User preferences, custom perspectives, cached data for plug-ins, etc all stored in the workspace
Multiple workspaces can be maintained
Only one can be active within each CCS instance
The same workspace cannot be shared by multiple running instances of CCS
It is not recommended to share workspaces amongst users 31

32. Eclipse Concept: Workbench
Workbench refers to the main CCS GUI window
The Workbench contains all the various views and resources used for development and debug

33. Eclipse Concept: Perspectives
Defines the initial set and layout of menus/toolbars/views in the Workbench window
Each perspective provides a set of functionality aimed at accomplishing a specific type of task (CCS Edit for project development, CCS Debug for debugging, etc)
CCS will automatically switch to the CCS Debug perspective when the debugger is started

34. Perspective: CCS Simple
Single perspective that combines just the most common features of the CCS Edit and CCS Debug perspectives
Simplifies the environment for new users
Avoid perspective switching when starting a debug session
Debug view
Project Explorer view

35. Eclipse Concept: Focus
Focus refers to the highlighted portion of the workbench
Can be the editor, a view, a project, etc.
This concept is important since several operations inside Eclipse are tied to the element in focus
Project build errors, console, menu and toolbar options, etc.
The OutOfBox_MSP432P401R project is in Focus since it has been selected. So pressing the Debug button will build the project and start the debugger for the OutOfBox_MSP432P401R project. Note how the project in focus is also highlighted in bold and with the word Active next to it for easy identification

36. Eclipse Concept: Views
Views are windows within the main Workbench window that provide visual representation of some specific information
Most views can be accessed in the menu View
Can be identified by the organization in tabs
Active tab (in focus)
Inactive tab
(out of focus)

37. View: Resource Explorer
Easily access a broad selection of software packages including:
controlSUITE
MSPWare
TivaWare
TI-RTOS
Guides you step by step through using examples
Browse resources:
Documentation
Videos

38. Eclipse Concept: Projects
Projects are typically a collection of files and folders
Files/folders can be added or linked to the project
Adding file/folder to project
Copies the file into your project folder
Any file physically in the project folder is considered part of the project
Linking file/folder to project
Makes a reference to the file in your project (file stays in original location)
Projects are either open or closed
Closed Projects:
Still defined to the workspace, but it cannot be modified by the Workbench
Closed projects require less memory and are not scanned during routine activity
Projects that are not part of the workspace must be imported into the active workspace before they can be used 38

39. View: Project Explorer
Displays all projects defined in the active workspace
The view is a loose representation of the file system of the project folder
Linked files are marked with a special link graphic in the icon
Files can be easily referenced and opened from the Project Explorer view

40. Types of Projects CCS Project (Managed Make Project)
Default CCS project (RTSC or non-RTSC)
Manages build tools directly
No makefile editing (auto-generates makefiles on build)
Full support via CCS GUI
Modify build properties and build tools
Default source indexer and error parser support
Standard Makefile Project
Re-uses existing makefiles
Simple integration with arbitrary build systems
Any build system that supports command line build can be covered using this mechanism
Parsing of toolchain output to generate error markers
Manual modification of the makefiles
CCS is used to build, not manage makefiles

41. Generated Makefiles CCS projects are Eclipse managed make projects
Makefiles are auto-generated when building a CCS project
Main makefile and several *.mk include files are generated in the active project configuration folder:
makefile: Main makefile that includes the generated *.mk files
All of the sources participating in the build are defined in the below *.mk files
objects.mk
sources.mk
subdir.mk
subdir_vars.mk
Main makefile is built using ‘gmake’ (provided with CCS)

42. Project Metadata Files
A project consists of a project folder that contains the following project metadata files and folders:
.ccsproject: Stores project settings contributed by TI
Ex: Stores initial device/toolchain settings entered by user at project creation
.cproject: Stores project settings contributed by CDT
Ex: Stores most of the build properties under the ‘Build’ section (most of the compiler/linker options)
.project: Stores project settings contributed by Eclipse
Ex: Stores information for linked resources, linked resource variables, resource filters
.settings (folder): Stores project specific settings that differ from the default CCS settings (workspace preferences)
makefile.defs (SYS/BIOS): Additional make rules included by the generated project makefile for SYS/BIOS projects
.ccsproject, .cproject, .project are XML files

43. Project Properties
The Project Properties dialog contains all the setting that apply to the project
Settings such as all compiler/linker options, pre/post build steps, project dependencies, device/connection information, and more can be set from this dialog
The dialog is accessible by right-clicking on a project in the Project Explorer view and selecting Properties
Device and high level settings
Compiler Options
Linker Options

44. Project Build Steps Scan Project
(*.*project, .settings, makefile.defs)
Generate makefiles
(makefile, *.mk include files)
Call pre-build steps (optional)
Call make
(gmake –k all)
Call post-build steps (optional)
Build Project
Build Complete
Pass build commands to build tools (RTSC, Compiler, Linker, etc)

45. Build Process 45

46. View: Console Multiple contexts You can open multiple Console views 46
Can display build messages or debug messages (including C/IO) depending on which console is selected
Automatically switches contexts when a new message occurs
Can use the Pin option to prevent this
You can open multiple Console views
C/IO output in one and build messages in the other 46

47. Debug Environment
A typical physical debugging setup consist of the debug system (CCS) and two main other components – Connection and Target (Board/Device):
Connection: Interface (JTAG, etc) between the host system running CCS and the target where the code is supposed to be executed
The Target board is the hardware that contains one or more devices required for the executable to be loaded to and run
This setup then allows the host system to have the necessary communicate with the target for debug purposes 47

48. Launching the Debugger
The debugger is launched from within CCS and performs the steps below
For flash based devices, the built-in flash programmer automatically handles the flashing process 48

49. View: Debug Main debug interface (must be open to control the target)
Debug view displays:
Target configuration or project
Call stack 49

50. Lab 1: Getting Started: BLINK LED Example 15 minutes
Refer to the Lab 1 section in your Lab Handbook for instructions 50

52. Basic debug: Blink LED Example52

53. Basic Debug: Exercise Summary
Key Objectives
Modify/Debug the Blink LED example
Basic Profiling
Tools and Concepts Covered
Basic Debug Concepts
Breakpoints/Watchpoints
Event Counters
Local History 53

54. Breakpoints Types Software (SW) Breakpoints Hardware Breakpoints
Implemented as an opcode replacement (limited to RAM)
(Generally) no limit to the number of software breakpoints available
Intrusive
Hardware Breakpoints
Implemented internally by the hardware (on-chip emulation module)
Limited number (varies with on-chip emulation module)
Two types of hardware breakpoints
Program: Monitor activity at a program address (or addresses)
Data: Monitor activity at a data address (also known as ‘watchpoints’)
Non-intrusive
vs._Software_Breakpoints 54

55. View: Breakpoints View all available breakpoints
Watchpoints and HW Event Counters can be also controlled and viewed
Enable/Disable individual breakpoints
Access/modify breakpoint properties
Set conditions to trigger
Specify various actions when the breakpoint is triggered
Refresh All Windows or update a specific view
File I/O
Run a GEL expression 55

56. View: Disassembly
View disassembled code, optionally interleaved with C source
Toggling the Show Source button toggles interleaved C source with the disassembly
Type symbol names (such as main) in the address field to view code at that address 56

57. More Debugging
Many other debugging specific views are available from the View menu
Memory Browser: View the contents of memory
Registers: View register values
Disassembly: View disassembled code
Breakpoints: View breakpoints
Modules: Browse loaded debug symbol information 57

58. Debugger Options
Many debugging features can be enabled/disabled from the Debugger Options
During a debug session in the CCS Debug perspective:
Tools -> Debugger Options
Configure a variety of debug options like [enable/disable]:
Auto-run to a label (main)
Auto-connect to a HW target
Program verification on load
Reset target on program load or restart
Halt target on debugger access (disable real-time accesses)
etc…
Use the Remember My Settings option to have the settings apply for subsequent debug sessions 58

59. View: History CCS keeps a local history of source changes
Switch to the CCS Edit perspective
Right-click on a file in the editor an select Team -> Show Local History
Opens History view
Use the History view to compare the current source file against any previous version or replace it with any previous version
Double-click on a revision to open it in the editor
Right-click on a revision to compare that revision to the current version
History view
File Comparer 59

60. Local History - Project
CCS keeps a local history of files for the project
Recover files deleted from the project
Right-click on the project and select Recover from Local History in the context menu 60

61. Lab 2: basic debug: Blink LED Example 30 minutes
Refer to the Lab 2 section in your Lab Handbook for instructions 61

63. Optimizer Assistant: blink LED example63

64. Optimizer Assistant: Exercise Summary
Key Objectives
Get familiar with the Optimizer Assistant
Tools and Concepts Covered
Optimizer Assistant
Memory Allocation view
Project Properties 64

65. Optimizer Assistant 65

66. Motivation
Too much emphasis on saving memory can cost you battery life
Compiler options to save memory can also reduce code performance
Slower code  more cycles  more power consumption
The answer is using the perfect combination of compiler options
For the speed vs size trade-off
For optimization level
Finding those compiler options is a matter of experimentation
No one size fits all solution
All that experimenting can be difficult
But not if you use the … Optimizer Assistant!

67. Background Review two important compiler options
--opt_for_speed
--opt_level
These options are the point of experimentation by Optimizer Assistant

68. Trade-off Speed vs Size
Option --opt_for_speed=value
Valid values 0-5
Best choice is often the largest size that still fits
Find it by letting Optimizer Assistant experiment for you
0 - Smallest Size
5 - Highest Speed
The valid values are The value 0 means always favor size over speed. The value 5 means always favor speed over size. Values in between adjust that trade-off accordingly.

69. Optimization Only a rough summary Optimize for size or cycles?
Option
Range of Optimization
--opt_level=off
None
--opt_level=0
Statements
--opt_level=1
Blocks
--opt_level=2
Functions
--opt_level=3
Files
--opt_level=4
Between files and libraries
Only a rough summary
Some level 0 and 1 optimizations range farther
Optimize for size or cycles?
Many optimizations save both size and cycles
Reducing cycles also reduces power consumption
--opt_level and --opt_for_speed are considered separately
The chief difference between levels of optimization is how much of the source code is considered at once in order to make good decisions about how to improve compiler output. Higher levels of optimization tend to generate better output. All that said, there are instances of level 0 and 1 optimizations which consider a bit more source code that what is reflected here.

70. How to Start Presume a successful build
Focus on Problems and Advice view
Select the Advice view
Scan through advice entries
Select each entry
An entry may be too long to see it all
Look at bottom CCS border to see more of the message
Double click on the indicated advice entry
Illustrated by the following set of screen shots

71. View: Advice Main dashboard for the Optimizer Assistant suite of tools
Displays the generated advice from the Optimizer Assistant
Entries can be selected to provide more details or even apply changes (apply compiler options) when applicable

72. Example: EZ430 Chronos
Advice View

73. Example: EZ430 Chronos
Advice Entry

74. Example: EZ430 Chronos
See More

75. Example: EZ430 Chronos
Double-click

76. Example: EZ430 Chronos Choose the compiler option to experiment on
Speed vs size tradeoff --opt_for_speed
Optimization --opt_level
Click Start

77. Example: Optimizer Assistant in Action
Project is built 6 times with different --opt_for_speed settings
Remembers how much flash memory is needed for each setting

78. Example: Results - opt_for_speed
YELLOW  it fits, but you can do better
GREEN  recommended
RED  Not enough flash (doesn’t fit)
Check mark by current setting
Results for varying optimization look different

79. Example: Results - opt_level
Different color scheme for optimization
RED  too big
BLUE  it fits
Check mark by current setting

80. Example: Next Steps Hover mouse over any row Pop up shows you a choice
--opt_for_speed=2 chosen above
Pop up shows you a choice
Change project settings to that option
Debug the program built with that option
Not allowed on red rows
Measure to see if performance and power consumption meet goals

81. Example: Memory Allocation View
Shows details of how much FLASH and RAM is being used
Can drill down and see details by section

82. View: Memory Allocation
Graphically displays the memory allocation details of the selected project
Can provide recommendations for alternative object placements for cases where memory allocation failed
Created by reading the data from a linker generated xml file
Shows memory usage of various sections
Expand top nodes to show breakdown of each section

83. Lab 3: Optimizer Assistant: blink LED example 20 minutes
Refer to the Lab 3 section in your Lab Handbook for instructions 83

85. real-time debug: Out of Box Experience Demo85

86. Real-Time Debug: Exercise Summary
Key Objectives
Demonstrate how to access/modify memory in real time when processor is running
Tools and Concepts Covered
Real-time access to memory
Continuous refresh in views 86

87. What is Real-Time Debug?
Stop Mode Debug (traditional debugging)
require the processor to be completely halted to access memory and registers
stops all threads and prevents interrupts from being handled
Stop Mode can be used as long as system/application does not have real-time constraints, but is very undesirable for real-time applications
Real-time Debug may enable 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
Real-time debug capabilities vary by device and are supported via different methods 87

88. Real-Time Debug Capabilities on Cortex-Mx
Access to memory while the processor is running
Supported through the DAP (Debug Access Port)
DAP is part of the ARM emulation logic and enables the debugger to access memory of the device without requiring the processor to enter the debug state
CCS will use the DAP “under the hood” to make real-time memory accesses
Default behavior of CCS is to always make a real-time access to memory (if possible) 88

89. Viewing Real-Time Accesses with CCS
To enable/view real-time access to memory and registers, click on Continuous Refresh in Memory Browser and Registers view in CCS Continuous Refresh will periodically refresh the debug views
Default refresh interval is 500 ms
Default refresh interval is configurable 89

90. Lab 4: real-time debug Out of Box Experience Demo 15 minutes
Refer to the Lab 4 section in your Lab Handbook for instructions 90

92. Serial Wire Output (SWO) Trace: Out of Box Experience Demo92

93. SWO Trace: Exercise Summary
Key Objectives
Get familiar with the capabilities of SWO Trace
Tools and Concepts Covered
Target Configurations
Data Visualization views
SWO Trace Use Cases
Statistical Function Profiling
Data Variable Tracing
Interrupt Profiling 93

94. Target Configurations94

95. Target Configuration Files - Basics
Target Configuration files are xml files that define the connection and device (have a file extension *.ccxml)
Used by CCS to start a debug session for a particular target
You must have a valid target configuration file for your device to start a debug session!
The Target Configurations view is used to manage and work with target configuration files
Target Configuration Editor is used to create/modify target configuration files
Basic tab is intended to be used by majority of end users
Advanced tab is intended to be used for adjusting default properties, initialization scripts or creating target configurations for new boards/devices
Target Configurations can be generated and maintained by the Project Wizard
Target Configuration file is added to the project

96. View: Target Configurations
Target configurations are easily deleted, copied and opened for inspection (XML files)
Launch a debug session quick: right-click on target configuration and select Launch Selected Configuration
Debug will use target configuration that is identified with [Default] tag in Target Configurations view
Right-click on a file and select Set as Default to make it the default
Debug will also use the [Default] if there is no target configuration file in the project
To associate an existing file to a project: right-click on target configuration and select Link File To Project

97. View: Target Configurations Editor (Basic)
1. Select your Connection (emulation)
3. Save the file
2. Select your device
4. Test/verify your target connection

98. View: Target Configurations Editor (Advanced)
Connection Properties
JTAG/SWD Mode
CPU Properties
GEL startup initialization script

99. GEL (General Extension Language)
‘C’ like scripting language that extends CCS usefulness
Interfaces to debuggers expression evaluator
You can enter expressions in:
GEL file
Expressions view
Conditions on breakpoints
Scripting Console
Many built-in GEL functions for common actions
GEL callback functions for when certain debugger events occur (debugger launch, etc)
Create custom GEL functions for additional functionality
Automate several steps within one GEL function
Create GEL “hotmenu” items for easy access from the ‘Scripts’ menu

100. Example GEL Script menuitem "evm_am3517" StartUp() { // Do nothing }
OnTargetConnect()
Startup_Sequence();
OnFileLoaded()
GEL_Reset();
GEL_Restart();
OnReset()
OnRestart()
hotmenu Startup_Sequence() {
GEL_Reset();
GEL_MapOff();
GEL_MapReset();
MemoryMap_Init();
GEL_MapOn();
GEL_TextOut("EVM AM3517 Startup Sequence Complete\n"); }
MemoryMap_Init()
/* !! FOLLOWING MEM SPACE TO BE CONFIGURED PROPERLY !! */
GEL_MapAddStr(0x , 0, 0x , "R|W", 0); /* GPMC */
GEL_MapAddStr(0x , 0, 0x4020FFFF, "R|W", 0); /* GPMC */
/* L4-peripheral memory space mapping */
GEL_MapAddStr(0x , 0, 0x , "R|W|AS4", 0); /* system control - module */
GEL_MapAddStr(0x , 0, 0x , "R|W|AS4", 0); /* system control - L4 interconnect */
...

101. GEL Limitations Can only be interfaced from within a CCS debug session
GEL supports only debug actions from within a CCS debug session
No project management support
Asynchronous behavior of built-in functions
Difficult to create long complex scripts
Built-in callback functions help but not enough
Cannot create custom callback functions
GEL was never meant for full blown automation purposes like overnight testing or batch-runs
Debug Server Scripting (DSS) is a better solution for full automation

102. Serial Wire Output (SWO) Trace
102

103. What is Serial Wire Output (SWO) Trace?
A set of debugging tools based on ARM hardware components that allow users to trace the flow of data from a big picture perspective
Not related to EnergyTrace+
Both use the PC for data
Share the same COM port
Supported by CCS through a variety of pre-configured common use-cases
Statistical Function Profiling
Data Variable Trace
Interrupt Profiling
Custom Core Trace
What is Serial Wire Output (SWO) Trace?
SWO Trace is an ARM debugging tool that is provided because the MSP432 has an ARM Cortex-M4 processor.
Not related to EnergyTrace+ in any way; only similarities are both use the PC for data, and they share the same COM port

104. Requirements Supported on the following devices
MSP432
CC13xx/26xx
TM4C (Tiva C)
Supported with the following debug probes
XDS110
XDS200
What is Serial Wire Output (SWO) Trace?
SWO Trace is an ARM debugging tool that is provided because the MSP432 has an ARM Cortex-M4 processor.
Not related to EnergyTrace+ in any way; only similarities are both use the PC for data, and they share the same COM port

105. Data Watchpoint and Trace Instrumentation Trace Macrocell
Overview
LOCAL
Time STAMP
Tiva (TM4C)
MSP432
TPIU (SWO)
TRACESWO
TDO
(SWD mode)
GPIO
DWT
ITM
Data Watchpoint and Trace
(hardware events)
PC value tracing
Interval driven: min 64 cycles
Exception trace
Entry
Exit
Return
Data tracing
Reads and/or Writes
Counters
Cycle
Special Instructions:
load-store, sleep etc.
Counter overflows 256 cycles
Instrumentation Trace Macrocell
(software messages)
Stimulus ports: 256 (32) channels
Byte
Half word
Word
CCS decodes channel 0 as strings
Serial Wire Output
Pin Protocol
Manchester
UART
Data rate
Trace clock/prescalar
CC13xx
CC26xx
XDS2xx
XDS110
Debug
Probes
Statistical Function Profiling
Exception Profiling
Data Variable Trace
Custom Core Trace
CCS Usecases
(Windows and Linux)

106. Data Watchpoint and Trace Unit (DWT)
Contains 3 configurable comparators:
Hardware watchpoint
PC sampler event trigger
Data address sampler event trigger
Counters including:
Clock cycles (CYCCNT)
Folded instructions
Load Store Unit (LSU)
Sleep cycles
Interrupt overhead
First, we can look at the DWT. The DWT contains many triggers and counters that provide data for other modules to use.

107. Instrumentation Trace Macrocell (ITM)
Generates packets of information
Sends packets to Serial Wire Output (SWO)
DWT creates the hardware-based packets
Watchpoints for variables
PC sampler event trigger
Clock cycle counter
Software packets generated by user via code
Creates packets when data is sent to ITM ports
ITM library can be used to send data to ports
This leads into the ITM. The ITM generates hardware and software packets of information that are sent to the TPIU and outputted through the SWO. The DWT provides the data for the hardware packets, and the software packets are generated when information is written to or read from the ITM ports.

108. What Can I Do With SWO Trace?
Statistical Function Profiling
Data Variable Tracing
Interrupt Profiling
Custom Core Trace
The usecases in CCS are Statistical Function Profiling, Data Variable Tracing, Interrupt Profiling, and a unique, customizable option called Custom Core Trace.

109. Statistical Function Profiling
What (is it) / How (does it work)?
Periodically checks the Program Counter (PC)
PC determines which function is being executed
Why (is it useful)?
Shows functions called and frequency of each
Helps determine which functions are more crucial
For Statistical Function Profiling, the DWT uses the PC Sample Event Trigger and Clock Cycle Counter to periodically sample the PC. From the PC, the system can detect which function the program is currently in. This information is sent to the ITM.
Statistical Function Profiling tracks function calling and frequency, so you can see which functions are most crucial for the program. You can focus your efforts on those functions for lowering power usage and other things.

110. Data Variable Tracing What/How? Why?
Tracks reads/writes to a memory location
Why?
See the big picture view of changes to a variable over time
For Data Variable Tracing, the DWT tracks reads and writes to a specific memory location and sends the data to the ITM.
Data Variable Tracing lets you see the large-scale view of what is going on to a variable or memory location. This lets you see if it is doing the right thing.

111. Interrupt Profiling What/How? Why? Interrupts noticed by DWT
Logged and outputted by ITM
Why?
Helps user to understand priorities and pre-empting of interrupts
Observe when interrupts were entered and exited
For Interrupt Profiling, the DWT uses the Interrupt Counter and Interrupt Overhead Counter to track interrupt enters and exits. The ITM logs this information and outputs it.
Custom Core Trace at the most basic level tracks software writes to the ITM ports. It can be configured with the additional other DWT triggers, though.
Interrupt Profiling shows you when interrupts were entered or exited, and the priorities for preempting each other. This makes sure your priorities are set up correctly.

112. Custom Core Trace What/How? Why? Tracks writes to ITM ports
Can be configured with additional triggers
Why?
Similar to printf style debugging (more user control)
Allows running of several use-cases at the same time
Custom Core Trace is a customizable option that at the most basic level tracks software writes to the ITM ports. It can be configured with the additional other DWT triggers, though.
Custom Core Trace is like printf style debugging, but with its customization options, you can run more than one of the other three usecases at the same time. You can also track more than one variable or memory location at the same time.

113. Summary
SWO Trace allows you to maximize the use of on-chip hardware components
Provides users with a big-picture view of software
Easy to use with the MSP432 LaunchPad; no additional hardware required
CCS offers:
Three easy to use defined usecases
Custom Core Trace for advanced configuration
References:
TI Application Note:
In summary, SWO Trace is a powerful tool offered by ARM hardware that lets users see the large-scale view of what is going on. It is easy to use with the MSP432 LaunchPad, and offers three predefined, easy to use usecases, and Custom Core Trace, a powerful, configurable usecase.

114. Lab 5: SWO Trace out of box experience demo 30 minutes
Refer to the Lab 5 section in your Lab Handbook for instructions
114

115. Thank You!