Code Composer Studio IDE Version 20.4.0 for MSPM33 MCUs

Table of Contents

• Read This First

• Software Installation

• Development Flow

• Debugging the Application

• Known Issues and Frequently Asked Questions (FAQs)

Read This First

How to Use This Guide

This guide describes only the setup and basic operation of the software development environment, but it does not fully describe the MSPM33 microcontrollers or the complete development software and hardware systems. For details of these items, see the appropriate TI and CCS documents listed in section Related Documentation From Texas Instruments.

Information About Cautions

This guide may contain cautions.

Caution - This is an example of a caution statement. A caution statement describes a situation that could potentially damage your software or equipment.

Read each caution carefully.

Related Documentation From Texas Instruments

MSPM33 development tools documentation:

• XDS110 Debug Probe User’s Guide

MSPM33 device documentation:

• LP-MSPM33C321A User’s Guide

• MSPM33 C-Series Technical Reference Manual

Code Composer documentation:

• Code Composer Studio Documentation

• Code Composer Studio Theia User’s Guide

If You Need Assistance

The E2E Community Support Forums for MSPM33 MCUs are available to provide open interaction with peer engineers, TI engineers, and other experts. Additional device-specific information can be found on the MSPM33 website.

1. Software Installation

Code Composer Studio Theia IDE is available from TI.com.

MSPM33 microcontrollers and the MSPM33 SDK require CCS Theia 20.4.0 or higher.

See the MSPM33 SDK documentation for finding the right SDK for your IDE version.

2. Development Flow

This chapter describes how to use CCS Theia to run the demonstration programs and develop application software.

2.1 Overview

Code Composer Studio (CCS) Theia is an integrated development environment (IDE) that supports TI’s Microcontroller and Embedded Processors portfolio. Code Composer Studio Theia comprises a suite of tools used to develop and debug embedded applications.

This guide only explains some features and capabilities of the Code Composer Studio Theia IDE using MSPM33.

More documentation for CCS Theia is available at TI.com or in the Help menu included in the IDE.

2.2 Using SysConfig with CCS Theia

Some examples in the MSPM33 SDK have SysConfig support. SysConfig is an intuitive and comprehensive collection of graphical utilities for configuring pins, peripherals, radios, subsystems, and other components. SysConfig helps you manage, expose, and resolve conflicts visually so that you have more time to create differentiated applications.

The SysConfig tool is delivered as a standalone installer, it can be used on the cloud at dev.ti.com, or it’s integrated into CCS Theia for better and easier experience.

After importing a MSPM33 project in CCS Theia, simply double-click the .syscfg file and this will open SysConfig.

For more information about using SysConfig with MSPM33, visit the Using SysConfig with MSPM33 guide.

2.3 Stack and Heap Management and Linker Files

The reserved stack and heap size can be configured using project settings or in the linker files.

2.3.1 Configure Stack and Heap using TI Arm Clang compiler

Right-click on a project and select Properties. Select Build → Tools → Arm Linker → Basic Options and set the stack and heap accordingly.

The stack and heap can also be modified directly on the linker .cmd file by adding or editing --stack_size=xx or --heap_size=xx.

2.3.2 Configure Stack and Heap using Arm GCC

The stack can be modified directly on the linker .lds file by adding or editing _Min_Heap_Size = xx or _Min_Stack_Size = xx.

2.4 How to Generate TI .TXT (and Other Format) Files

CCS includes utilities which can be used to generate output objects in multiple formats for use with programming tools such as UniFlash.

2.4.1 Using Arm Hex Utility

The following steps explain how to enable the TI TXT format using the Hex Utility which is integrated into CCS.

Right-click on a project and select Properties. Select Build → Tools → Arm Hex Utility → Output Format Options. Then select the TI-TXT hex (–ti_txt) option.

This same process can be used to generate other formats; however, some formats might require other parameters.

A common one is Intel HEX format which in addition to selecting the output format Intel hex (–intel, -i), requires to specify the memory and ROM width as parameters.

When using Intel HEX for MSPM33, select a memory and ROM width of 8 in Build → Tools → Arm Hex Utility → General Options.

For more information, visit Hex utility in CCS.

2.4.2 Using Objcopy Utility

CCS includes the Arm Objcopy Utility which is a LLVM-based tool that can be used to generate binaries in multiple formats.

The following steps explain how to enable intel Hex format using ObjCopy.

1. Right-click on a project and select Properties. Select Build → Tools → Arm ObjCopy Utility and select Enable Arm Objcopy Utility.

2. Specify the output file name using .hex extension.

3. Specify the ihex output format.

For more information about Objcopy, visit this Objcopy guide.

2.5 Running from SRAM

The examples included in the MSPM33-SDK will commonly have linker files which create applications which are intended to run from internal Flash and will execute after reset or power cycling the device. However, in some scenarios, it can be useful to download and execute code from SRAM.

This section describes step-by-step instructions to execute some functions or complete applications from SRAM.

2.5.1 Running a complete application from SRAM

The following steps show how to modify a basic gpio_toggle_output example for the LP_MSPM33C321A to run from SRAM. Similar steps apply to other examples and devices.

1. Open the linker .cmd file and modify it to use SRAM as shown below:

2. Disable the System Reset which is executed by default in CCS.

   CCS includes .gel files which execute certain functions on the device. These files are included inside the CCS installation folder at <ccs>\ccs_base\emulation\gel>. Make sure to set the highlighted address in OnTargetConnect function to be the same as the .intvecs address defined in linker file. The screenshot below shows the modification necessary for MSPM33C321A:

3. Download code and note that the device will execute from SRAM.

2.5.2 Running a function from SRAM

The following steps show how to declare a function which is executed from SRAM.

1. Move the function to the .TI.ramfunc section. This can be accomplished by declaring the function with the attributes __attribute__((section(".TI.ramfunc"))) __attribute__((noinline)) as observed below:

2. The linker file should include a placement of .TI.ramfunc. Note that the linker files included in MSPM33-SDK already include this placement but it will only be applicable if any functions are placed in .TI.ramfunc.

3. Download code and note that the device will execute the function from SRAM.

3. Debugging the Application

The following debug probes have been tested successfully with Code Composer Studio Theia IDE.

• TI XDS Tools, including the XDS-110 integrated into MSPM33 LaunchPads.

3.1 Using TI XDS Tools

TI offers a range of debug probes for Arm-based devices, including the XDS-110 which is integrated with MSPM0 LaunchPads.

To use the TI-XDS debug probes, open the project options, click on General → Connection and select Texas Instruments XDS110 USB Debug Probe.

3.1.1 Flash Loader

The Flash Loader settings allow to configure some settings when programming and erasing the device.

To view and modify these settings, open the project properties and select Debug → Category:MSPM33 Flash Settings.

The Flash Loader has the following options:

• Reset Configuration: allows to perform soft or hard reset before and after programming.

• Program Configuration: enables/disables CRC verification while programming. Note that CRC validation of NONMAIN is performed when programming/erasing NONMAIN regardless of this setting.

• Erase Configuration: configures the behavior when erasing memory. The options are:

  • Erase MAIN memory only: Only MAIN memory will be mass erased. An error will be thrown when attempting to write NONMAIN.

  • Erase MAIN and NONMAIN memory: Both MAIN and NONMAIN will be mass erased. See Erasing and Updating NONMAIN Memory for information about NONMAIN usage.

  • Erase MAIN and NONMAIN necessary sectors only: Only sectors being updated will be erased, including both MAIN and NONMAIN. Check the device datasheet for information on the size of flash sectors. See Erasing and Updating NONMAIN Memory for information about NONMAIN usage.

  • Erase MAIN memory sectors by range: Only sectors defined between Sector Erase Start Address and Sector Erase End Address will be erased. Check the device datasheet for information on the size of flash sectors and note that the addresses are inclusive. For example, a region from 0x0000_0100 to 0x0000_0400 on a MSPM0 device with 1kB sectors will erase sectors 0x0000_0000-0x0000_03FF and 0x0000_0400-0x0000_07FF. Note that only sectors in MAIN will be erased. An error will be thrown when attempting to write NONMAIN.

  • Do not erase Flash memory: Flash will not be erased. An error will be thrown when attempting to write NONMAIN without erasing.

• Advanced Configuration: disables validating the device ID. Used for debugging purposes and not recommended to disable.

• Enable Verbose Output: enables showing debug information while running the flash loader.

3.1.2 Erasing and Updating NONMAIN Memory

Caution: Extreme care should be taken when erasing and programming NONMAIN. If done incorrectly, the device will become locked in a permanently unrecoverable state.

NONMAIN is a dedicated region of flash memory which stores configuration data which define the behavior of the device after booting. NONMAIN should not be used for any other purpose. See the device Technical Reference Manual for more information.

TI recommends using the NONMAIN configurator available in SysConfig when configuring NONMAIN. See Using SysConfig with MSPM33 for more information.

As described in the Flash Loader section, NONMAIN is erased by selecting Erase main and NON-MAIN memory or Erase MAIN and NONMAIN necessary sectors only in the erase configuration.

Note that the Flash Loader will erase NONMAIN if any of these options are enabled; however, it will run a CRC after the programming sequence is completed, and it will attempt to restore default values if NONMAIN is corrupted.

3.2 Breakpoint Types

The CCS Theia debugger uses a limited number of on-chip debugging resources (specifically 4 hardware breakpoints and 2 hardware watchpoints). Software breakpoints in Flash are not supported on MSPM33. This means that a maximum of 4 hardware breakpoints can be set within CCS Theia.

CCS Theia can use a breakpoint to stop at main or halt the device at exit. These settings can be updated in the project properties by selecting Debug → Category:Program/Memory Load Options.

3.3 DSSM Commands

MSPM33 allows communication to the device over SWD from a debug probe using the Debug Subsystem Mailbox (DSSM). These commands are not available in SWD security level 2, but they are optionally available in security level 0 and 1. See the device Technical Reference Manual for more information about security policies and DSSM.

The MSPM33 CCS support package includes GEL files not only to perform device initialization, but to send DSSM commands which are explained in the following sections.

For more information about GEL commands in CCS, visit the CCS online documentation.

3.3.1 DSSM Mass Erase and Factory Reset

• DSSM Mass Erase: A DSSM mass erase is an erase of the MAIN flash regions only, which typically includes the user application. NONMAIN flash region are not affected by a mass erase. A mass erase is useful for erasing all application code and data while leaving the device configuration itself intact.

• DSSM Factory Reset: A DSSM factory reset is an erase of the MAIN flash regions followed by a reset of the NONMAIN flash region to default values. Such an erase is useful for completely resetting the NONMAIN boot policies while also erasing the application code and data.

The SWD mass erase and factory reset DSSM commands superseded any static write protection policies. For example, if SWD factory reset is configured to be enabled or enabled with password, the NONMAIN configuration data can be reset even if it is statically write protected.

To execute a DSSM Mass Erase or DSSM Factory Reset, follow the next steps:

1. Go to an active project and open the targetConfigs folder.

   

2. Right-click the .ccxml file and select Start Project-less Debug.

   

3. On the debugger window menu, select Scripts → MSPM33xxxx_Commands (where MSPM33xxxx depends on the current MSPM33 device), and select one of the following options:

   • MSPM33_MailboxMassErase_Manual: A mass erase will be performed asking the user to press the reset button.

   • MSPM33_MailboxMassErase_Auto: A mass erase will be performed forcing reset using the XDS110 reset line.

   • MSPM33_MailboxFactoryReset_Manual: A factory reset will be performed asking the user to press the reset button.

   • MSPM33_MailboxFactoryReset_Auto: A factory reset will be performed forcing reset using the XDS110 reset line.

   

3.3.1.1 DSSM after Power-up

The device might not respond to DSSM commands in some scenarios such as when the reset line or SWD pins are used for other functions. In such conditions, it can be useful to follow the next steps:

1. Power off the device

2. Hold the reset line (NRST) low

3. Power up the device, while holding NRST low

4. Execute one of the Manual DSSM commands mentioned in previous section

5. When prompted, release NRST

4. Known Issues and Frequently Asked Questions (FAQs)

Please refer to Known Issues and FAQ inside the SDK.