MSPM0 SDK Known Issues and FAQ (Frequently Asked Questions)

Introduction

This page documents the list of Known Issues and Frequently Asked Questions related to the MSPM0 SDK.

Table of Contents

• Known Issues
• FAQ (Frequently Asked Questions)
• Addendum A - Debugging in Low Power Modes
• Addendum B - Preventing Programming Issues and Recovery
• Technical Support and Product Updates

Known Issues

Silicon

• See the errata documents on the corresponding product pages.
• Known silicon issues and workarounds for early experimental samples are described in the “MSPM0G and MSPM0L Families: Functional Differences With Early Samples” document. Please request your TI sales office for access to this document.

Programmers/Debuggers

• Programmers and debugger might experience connection problems in some scenarios.
  • Please view Addendum A - Debugging in Low-Power modes for a more detailed description to debug in STOP/STANDBY.
  • Please view Addendum B - Preventing Programming Issues and Recovery for a more detailed description of the workarounds when device connection fails.

Middleware

SMBus

• Some SMBus features such as ARP or SMBAlert are not implemented.
  • Workaround: the current supported features and pending features are listed in SMBus documentation. More features will be added on next releases.

BIM

• Execute-in-place (XIP) is the only currently supported method of image management for the boot image manager. This means that images must be compiled with respect to the slot they will be executed from. In practice, this could mean maintaining two images or configurations for each version.
  • Workaround: the MSPM0 SDK includes examples using XIP. Image swapping is planned for a future release

Motor Control

• The offline version of motor control demo GUIs might experience connection issues.
  • Workaround: Use the online GUIs in TI Gallery for evaluation purposes.

SysConfig

• In SysConfig, when selecting an option that is only available for MSPM0G, and then the device is switched to MSPM0L, this will cause an error in SysConfig.
  • Workaround: If switching devices from MSPM0G to MSPM0L, ensure to de-select any MSPM0G-specific options in the SYSCTL module before switching.
• When using SysConfig with a Board selected, if the user tries to switch to a different Board an error will occur.
  • Workaround: when switching, clear the Board field and switch to a different Device first, then switch to the desired Board.
• When selecting analog peripheral input/outputs that are able to function on the same pin at the same time, SysConfig will show a resource conflict error.
  • Workaround: Select the specific desired pin (do not leave as ‘Any’), and then select the option to ignore the error. This will once again enable code generation, and downgrade the error to a warning that can be suppressed as well.

IAR

• Building a new project with a .syscfg file in IAR throws an error.
  • Workaround: Perform a “Clean” followed by a “Rebuild All” and a “Make”.

Keil

• Keil can’t connect to device using LaunchPad’s integrated XDS-110.
  • Workaround: Use CMSIS-DAP mode with XDS-110, or a different tool such as Keil ULINK, or Segger j-Link.
• Keil can experience connection issues using CMSIS-DAP mode.
  • Workaround: Some issues have been seen using USB hubs. Connect debugger directly to PC.

FAQ (Frequently Asked Questions)

SDK

Q: How do I use the SDK with CCS Theia, CCS, IAR, GCC, or Keil?

A: Refer to the Quick Start Guides which are included in the documentation of the SDK.

Q: How do I submit an SDK bug (Drivers, examples, SysConfig, documentation) or request a new feature?

A: To request a new feature or file a bug for header and support files, SDK DriverLib, Code Examples, SysConfig, or TI-Drivers, please contact your local sales representative or TI support team.

Drivers

Q: What types of drivers are supported?

A: DriverLib are low-level efficient drivers which provide full coverage of registers and functionality. It is more “granular” which some more knowledge of the hardware, but allows for more efficient code and smaller footprint and the use of SysConfig can simplify and accelerate code development.

TI-Drivers are higher level drivers. They have a larger code size since they have more functionality already implemented but require less knowledge of the hardware to use. The SDK currently contains preliminary support for some No-RTOS and RTOS Drivers. More TI-Drivers are under development.

SysConfig

Q: What is Clock Tree, and how do I use it?

A: Clock Tree is a module in SysConfig that allows the user to configure the clocking of a device graphically rather than using SYSCTL menus. It can be used in place of the SYSCTL clock configuration options in the module by selecting the Use Clock Tree configurable in SYSCTL. Refer to the Using SysConfig with MSPM0 guide for more details.

Q: What is Analog Configurator, and how do I use it?

A: The TI Analog Configurator is a standalone, graphical configuration tool designed to simplify and accelerate the design and enablement of an analog signal chain using a MSPM0 device with no traditional coding development necessary. This tool is intended to help MSPM0 users rapidly take their analog signal chain concept and create a buildable project that can be flashed to the device. Refer to the Analog Configurator Overview for more details.

RTOS

Q: Does the MSPM0 SDK support FreeRTOS?

A: Yes, currently the SDK does include the FreeRTOS kernel, a Driver Porting Layer (DPL), POSIX support, and a basic DriverLib FreeRTOS example supported with CCS Theia, CCS, IAR, and Keil.

Q: Does the MSPM0 SDK support TI-RTOS?

A: There are no plans to support TI-RTOS.

Q: Is the MSPM0 SDK planning to support other RTOS?

A: To request an RTOS, please contact your local sales representative or TI support team.

Middleware

Q: What middleware is currently supported?

A: Refer to the Documentation Overview for the full list of middleware that is currently supported by the SDK.

Q: Is TI planning to add MSPM0 support for CAN/LIN stacks from third-parties like Vector, IHR, Simma Software, etc.?

A: Several third-parties are already offering support for MSPM0 and will advertise it over the following days. More third-parties are adding support for MSPM0, but please contact the 3P directly, local sales representative or TI support team as needed.

Q: Is the MSPM0 SDK planning to support more middleware?

A: More middleware is being added and will be included in future releases. To request middleware, please contact your local sales representative or TI support team.

Q: What type of SW based diagnostics will be supported by the MSPM0 Diagnostic Library?

A: The high level description of what is included in the Diagnostic Library is listed below:

• APIs to:
  • monitor stack usage
  • detect stuck at faults in mcu data (internal data path) using class b test methodology
  • detect stuck at faults in the mcu addressing using class b test methodology
  • detect DC fault in variable memory using class b test methodology
  • detect all single bit faults in invariable memory using class b test methodology
  • detect clock wrong frequency using class b test methodology
  • detect stuck at faults in Program Counter using class b test methodology
  • detect stuck at faults in the MCU core registers using class b test methodology
• Collateral:
  • Diagnostic Library Safety Manual
  • Document code size for each API using compiler settings documented in the compiler qualification documents
  • include a chapter which describes class b testing techniques for Input/Output periphery
• Distribution:
  • distributed as a self-contained library installer including source code. To get access to the latest MSPM0 Diagnostic Library, please visit the Diagnostic Library Overview and follow the instructions to request access to the library.

General

Q: Can MSPM0 software be used in production and what type of support is expected for MSPM0 software products?

A: Most of the SDK code is provided under the 3-Clause BSD license.

Most of the SDK is being developed using a TI’s BaseLine quality flow and the MSPM0 SDK implements MISRA-C checks to ensure a high level of quality. However, validating the code on an end application is customer’s responsibility.

Some code such as the Diagnostics Library (which is licensed under a TI Commercial License) follows an even more strict development and testing process which provides a higher degree of reliability.

TI is and has been a leader in customer support in the semiconductor industry. TI is committed to provide support of the MSPM0 SDK as we have demonstrated over the years.

Q: If I have early experimental samples, how do I migrate my application to production samples?

A: Refer to the Early Samples Migration document for detailed information on how to migrate your application to a MSPM0 SDK version supporting production samples.

Tools

Q: What IDEs and compilers are we supporting?

A: The MSPM0 includes examples for:

• IDEs: CCS, CCS Theia, Keil, IAR
• Compilers: TI-Clang, GCC, Keil and IAR.

However, IDEs and compilers from other third-parties might be available and used with MSPM0.

Q: Does MSPM0 support ‘x’ tool?

A: Refer to the Tools Guide for information on the variety of tools from TI and 3rd parties that is supported by the MSPM0. However this is not a complete list of tools available for MSPM0, visit TI.com for more updates or request support from your 3rd party tool vendor.

Addendum A - Debugging in Low Power Modes

Description of the issue:

Devices can experiment SWD connection issues when going into STOP or STANDBY mode.

The effect of this limitation depends on the IDE and debugger implementation.

1. The debugger shows a warning error when the device goes into STOP/STANDBY.

This behavior is caused by the debugger continuously polling the AP interface and failing to communicate. In this scenario, the debugger shows a warning or prompts the user to try to reconnect. The warning typically appears periodically while the device is in low-power mode. The following image shows a warning when using IAR with Segger J-Link:

• Workaround:
  • Ignore the warning or retry the connection. The debugger will reconnect once the device goes back to RUN or SLEEP modes either periodically or with a breakpoint.

3. The debugger ends abruptly when the debugger tries to halt the device.

The debugger will be unable to halt the device on-demand, and it can either show a warning similar to case #1, or it can end abruptly. The following image shows an error when halting using IAR with XDS-110:

• Workaround:
  • Halt only when the device is in RUN mode.
  • If not possible, use hardware breakpoints or BKPT instruction to reconnect the debugger.

Summary of tested IDEs and debuggers

The following table shows a summary of some IDEs and debuggers tested:

IDE	Debugger tool	Going into LPM	Halting
CCS/CCS Theia	XDS-110	OK (warnings)	OK (warnings)
CCS/CCS Theia	Segger J-Link	OK (warnings)	OK (warnings)
IAR	XDS-110	OK	Error
IAR	Segger J-Link	OK (warning prompt)	OK (warning prompt)
IAR	IAR I-Jet	OK (warnings)	OK (warning prompt)
IAR	XDS-110 as CMSIS_DAP	OK (warnings)	OK (warning prompt)
Keil	XDS-110 as CMSIS_DAP	OK (warnings)	OK (warnings)
Keil	Segger J-Link	OK (warnings)	OK (warnings)
Keil	Keil ULINK	OK (warnings)	OK (warnings)

Addendum B - Preventing Programming Issues and Recovery

Description of the issue:

Programmers and debuggers can experience some issues when attempting to connect to the device under some scenarios:

• Reconfiguring SWD pins.
• Going into some low-power modes.
• Incorrect configuration of NONMAIN memory.

Preventive actions:

Some recommended workarounds to prevent these issues include:

Preventive Action #1.Use RUN or SLEEP mode during development.

Preventive Action #2. Delay entry into low-power mode in your application.

Preventive Action #3. Implement a recovery mechanism such as staying in RUN mode depending on pin configuration. The SDK includes a driverlib example sysctl_shutdown showing an implementation which selects the low-power mode depending on external pins.

Preventive Action #4. Ensure NONMAIN memory is not written incorrectly. NONMAIN can completely lock SWD and BSL and thus, it should only be written purposely. The NONMAIN configurator in SysConfig can aid in configuring NONMAIN. See the SysConfig Guide for MSPM0 for more details.

Preventive Action #5. Ensure BSL can be invoked using RESET and BSL_INVOKE pins.

Recovery actions:

If a device is locked, the following steps can be followed:

Recovery Action #1. Attempt to force a reset before connecting:

• Note that the IDE might already do this by default, it can prompt to force a Reset, or there can be a setting to enable a physical reset.

Recovery Action 2. Force BSL with debugger Reset:

• Press-and-hold the BSL_Invoke button while attempting to program. This method is more convenient than below but the IDE must have capability to force a physical reset.

Recovery Action 3. Force BSL with physical Reset:

• Press-and-hold the BSL_Invoke button while pressing and releasing the Reset button.
• The device should go to BSL and stay in Active mode for ~10secs.
• Attempt to program immediately after releasing reset.

Recovery Action 4. Force BSL with Power-cycle:

• Disconnect the board.
• Press-and-hold the BSL_Invoke button while reconnecting the board.
• The device should go to BSL and stay in Active mode for ~10secs.
• Attempt to program immediately after plugging the board.

Recovery Action 5. Force a DSSM Mass Erase: At the moment of this release, support for DSSM commands is implemented using CCS.

Follow instructions in the CCS IDE Guide for more information.

Recovery Action 6. Force a DSSM Factory Reset: At the moment of this release, support for DSSM commands is implemented using CCS.

Follow instructions in the CCS IDE Guide for more information.

Technical Support and Product Updates

• To request a new feature or file a bug, please contact E2E, or your local sales representative.