Table of Contents

Early Samples Migration Guide

Introduction

IMPORTANT: This guide is only applicable to customer who received early samples of MSPM33 and will migrate their existing application to production samples.

The purpose of this document is to highlight:

Customers using early samples are highly encouraged to migrate their applications to a MSPM33 SDK version supporting production samples. MSPM33 SDK support for experimental samples will not be supported long-term.

The section below describes the recommended tool versions which support production samples and provides migration guidelines for applications using DriverLib and SysConfig configuration files.

The guide assumes users are working in a Windows environment. However, the concepts discussed in this guide are also applicable to Linux and MacOS.

Updated information will be posted online at e2e.ti.com.

Which samples are supported by my current MSPM33 SDK?

How to determine MSPM33 sample versions

You have production samples if:

You have early samples if:

Important Documents

Tools Considerations

The table below lists the MSPM33 production compatible versions for use with production sample

Product Version
MSPM33 SDK 1.00 or later
SysConfig 1.26.0
Code Composer Studio (Eclipse) 20.4.0 or later
Code Composer Studio Theia 20.4.0
IAR Embedded workbench for ARM 9.70.1 or later
Keil MDK-Arm with uVision 5.38a or later

Code Composer Studio (CCS)

The following Code Composer Studio versions support production samples for MSPM33 devices:

IMPORTANT: For customers planning to work with early samples and production samples, it is highly recommended to have dedicated CCS installation under a different install path than the default installation path. For example, the CCS installation for production samples can be C:\ti\production.

IMPORTANT: Some Flash Loader settings changed between the CCS support package for early samples and production samples. When importing an example from early samples into a CCS with a newer support package, it is advised to check and confirm the flash erase settings as shown below:

IAR Embedded workbench for ARM

IAR Embedded workbench for ARM 9.70.1 or later supports production samples for MSPM33 devices.

IMPORTANT: For customers planning to work with early samples and production samples, it is highly recommended to have dedicated IAR installation under a different install path than the default installation path. For example, the IAR installation for production samples can be C:\Program Files\IAR Systems\production. For instructions to select a SysConfig in IAR please refer to Enabling SysConfig in IAR in the SysConfig guide.

DriverLib Changes

This sections summarized the APIs, defines, and enums which have been updated or removed in Driverlib. Customers can reference this section to determine the appropriate action needed to resolve compilation errors during the migration.

<Application_File>.syscfg comparison

This section highlights the differences between early sample and production sample .syscfg files and how to modify old .syscfg files to be compatible with production samples. Every project contains a .syscfg file that contains all the SysConfig configuration settings that are set via the GUI, and migrating to the latest SDK and SysConfig resulted in changes to certain parameters and functions. Each row reflects a change in the SysConfig GUI/SDK that resulted in a change to parameters. Rather than going through the GUI to make these changes, a user can directly modify this file via text editor to migrate the configuration settings to the latest version.

System Modules

UNICOMM:

UNICOMM naming convention is changed from older sample code and APL code.

The new naming convention can be seen here -

With the older sdk, in driverlib example, we used to see this kind of reference to the unicomm.

With this change, we can see this type of code change in example level sysconfig generated files(ti_msp_dl_config.h) -

This below picture shows the case when old unicomm naming was used -

This below picture shows the case when new unicomm naming is used -

There is no API level change for this naming change.