MSPM33 SDK Known Issues and FAQ (Frequently Asked Questions)

Introduction

This page documents the list of Known Issues and Frequently Asked Questions related to the MSPM33 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

Examples

• memory_hide_protect on IAR

Silicon

• Some SYSCTL registers such as crystals or PLL are retained in lower reset levels, as described in the Clock Module (CKM) section of the device TRM. This may cause an issue within SysConfig where SysConfig assumes a default POR configuration of SYSCTL registers during initialization, which can cause the application to get stuck in a clock initialization check if the SYSCTL registers are not properly reset after a lower reset level.
  • Workaround: The “Force Default Clock Configuration” option can be enabled in SysConfig to disable the PLL and HFXT to ensure default settings.
  • Workaround: If the LFXT is enabled, the internal LFOSC is disabled and LFOSC cannot be re-enabled other than by executing a BOOTRST.

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 of debugging in STOP/STANDBY/SHUTDOWN.
  • Please view Addendum B - Preventing Programming Issues and Recovery for a more detailed description of the workarounds when device connection fails.

SysConfig

• If we are using same pin for two HSADC instances, SysConfig will not show a resource conflict error.
  • Workaround: Make sure to not select the same pin.

FAQ (Frequently Asked Questions)

SDK

Q: How do I use the SDK with Code Composer Studio, IAR?

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.

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 MSPM33 guide for more details.

RTOS

Q: Does the MSPM33 SDK support FreeRTOS?

A: Yes, currently the SDK does include the FreeRTOS kernel supported with Code Composer Studio.

Q: Is the MSPM33 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 the MSPM33 SDK planning to support more middleware?

A: 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 MSPM33 Diagnostic Library?

A: The SDK currently don’t support any diagnostic library. In future releases, diagnostic library will come.

General

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

A: Most of the SDK code is provided under the BSD-3-Clause license. Refer to the Manifest for more details.

Most of the SDK is being developed using a TI’s BaseLine quality flow. However, validating the code on an end application is customer’s responsibility.

TI is and has been a leader in customer support in the semiconductor industry. TI is committed to provide support of the MSPM33 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 MSPM33 SDK version supporting production samples.

Tools

Q: What IDEs and compilers are we supporting?

A: The MSPM33 includes examples for:

• IDEs: CCS, IAR
• Compilers: TI-Clang, IAR.

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

Q: Does MSPM33 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 MSPM33. However this is not a complete list of tools available for MSPM33, 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 experience SWD connection issues when going into STOP, STANDBY, or SHUTDOWN 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/SHUTDOWN.

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 XDS-110:

• Workarounds:
  • If using the IAR IDE, download version 9.70.2+ or follow this guide to apply the low-power mode patch for IAR.

2. The debugger shows an error when attempting to flash a blank device

All blank devices will enter a low-power mode when they have been powered on for more than ~10 seconds. Depending on the IDE and debugger tool being used, an error or warning may be given when attempting to access the device while it is in a low-power state. The following image shows an error using IAR with XDS-110 when attempting to download a project to the device when it is in a low-power mode:

• Workarounds:
  • If using the IAR IDE, download version 9.70.2+ or follow this guide to apply the low-power mode patch for IAR.

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
Code Composer Studio	XDS-110	OK	OK
IAR	XDS-110	OK (5)	OK (5)

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. Delay entry into low-power mode in your application.

Preventive Action #2. 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 #3. Ensure NONMAIN memory is not written incorrectly.

Incorrect writes to NONMAIN can completely lock SWD and BSL. The Configuration NVM (NONMAIN Configurator) in SysConfig can aid in proper configuration of NONMAIN. See the SysConfig Guide for MSPM33 for more details.

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

Preventive Action #5. Use the latest version of the tool or apply their designated patch.

It is recommended to use the latest version of the tool. As an alternative to updating the tool, a patch or script can be used to enable low-power mode debugging.

Please refer to Preventive Action #7. Modifying the Power access point.

Preventive Action #6. Recommended IAR IDE version.

It is recommended that the user uses these versions of the IAR IDE.

• IAR IDE

  | Version |
  | ----------- |
  | 9.70.2+ |

Preventive Action #7. Modifying the Power Access Point.

If the respective tool does not have low-power mode handling, natively enabled. It is possible to enable it by modifying the Power Access Point on our devices.

To do so, please follow these steps during the initialization process of the tool:

1. Switch the Access Point selection to use the fourth Access Point. This is our Power-AP.
2. The address offset will be 0x00.
3. Write a 1 to the 3rd, 16th, and 20th bit of the Power-AP.
4. Executing these steps should enable low-power mode debugging with the respective tool.

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 method described in Recovery Action 3. Force BSL with physical Reset but the IDE must have capability to force a physical reset.

Recovery Action 3. Force BSL with physical Reset:

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

Recovery Action 4. Force BSL with Power-cycle:

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

Recovery Action 5. Force a DSSM Mass Erase: As of this current SDK release, support for DSSM commands is implemented using CCS and the MSPM33 Factory Reset GUI tool.

Follow instructions in the CCS IDE Guide and refer to the Tools Guide for more information.

Recovery Action 6. Force a DSSM Factory Reset: As of this current SDK release, support for DSSM commands is implemented using CCS and the MSPM33 Factory Reset GUI tool.

Follow instructions in the CCS IDE Guide and refer to the Tools Guide for more information.

Recovery Action 7. Force a DSSM Wait for Debug: As of this current SDK release, support for DSSM commands is implemented using CCS.

Follow instructions in the CCS IDE Guide.

Recovery Action 8. Force a DSSM Set Reset Mode: As of this current SDK release, support for DSSM commands is implemented using CCS.

Follow instructions in the CCS IDE Guide.

Note: 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 cases, it is recommended to issue a DSSM Mass Erase or Factory Reset while holding the reset line low during power-up. See CCS IDE Guide or Tools 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.