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.
- 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 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
- 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.
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.
2. The debugger shows an error when attempting to flash a blank device
All blank devices will enter a low-power mode 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:
- Workaround:
- Program the device first using Code Composer Studio, and then continue development using previous IDE.
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: As of this current SDK release, support for DSSM commands is implemented using CCS and the MSPM0 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 MSPM0 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.