Migration Guide From STM32® to Arm®-Based MSPM0

ABSTRACT

This application note assists with migrating from the STMicroelectronics STM32® platform to the Texas Instruments MSPM0 MCU ecosystem. This guide introduces the MSPM0 development and tool ecosystem, core architecture, peripheral considerations, and software development kit. The intent is to highlight the differences between the two families and to leverage existing knowledge of the STM32 ecosystem to quickly ramp with the MSPM0 series of MCUs.

Table of Contents

1. MSPM0 Portfolio Overview
2. Ecosystem and Migration
3. Core Architecture Comparison
4. Digital Peripheral Comparison
5. Analog Peripheral Comparison
6. Revision History

1 MSPM0 Portfolio Overview

1.1 Introduction

The MSP430™ MCUs have nearly 30 years of history as TI's classic microcontroller. The latest generation introduces the MSPM0 family. MSPM0 microcontrollers (MCUs) are part of the MSP highly-integrated ultra-low-power 32-bit MCU family based on the enhanced Arm® Cortex®-M0+ 32-bit core platform. These cost-optimized MCUs offer high-performance analog peripheral integration, support extended temperature ranges, and offer small footprint packages. The TI MSPM0 family of low-power MCUs consists of devices with varying degrees of analog and digital integration allowing engineers to find the MCU that meets their project's needs. The MSPM0 MCU family combines the Arm Cortex-M0+ platform with an ultra-low-power system architecture, allowing system designers to increase performance while reducing energy consumption.

The MSPM0 MCUs offer a competitive alternative to the STM32 MCUs. This application note assists with migration from STM32 MCUs to MSPM0 MCUs by comparing device features and ecosystems.

1.2 Portfolio Comparison of STM32 MCUs to MSPM0 MCUs

2 Ecosystem and Migration

MSPM0 MCUs are supported by an extensive hardware and software ecosystem with reference designs and code examples to get designs started quickly. MSPM0 MCUs are also supported by online resources, trainings with MSP Academy, and online support through the TI E2E™ support forums.

2.1 Software Ecosystem Comparison

2.1.1 MSPM0 Software Development Kit (MSPM0 SDK)

The MSPM0 SDK delivers software APIs, examples, documentation, and libraries that help engineers quickly develop applications on Texas Instruments MSPM0+ microcontroller devices. Examples are provided to demonstrate the use of each functional area on every supported device and are a starting point for your own projects. Additionally, interactive MSP Academy trainings are included in the MSPM0 SDK to provide a guided learning path.

The examples folder is divided into RTOS and non-RTOS subfolders (currently only non-RTOS is supported). These folders contain examples for each LaunchPad™ development kit and are organized into categories such as lower-level DriverLib examples, higher-level TI Drivers examples, and examples for middleware such as GUI Composer, LIN, IQMath, and others. For details, refer to the MSPM0 SDK User's Guide.

2.1.2 CubeIDE vs Code Composer Studio IDE (CCS)

Code Composer Studio IDE (CCS) is TI's equivalent of STM32's CubeIDE. CCS is a free Eclipse-based IDE that supports TI's microcontroller (MCU) and embedded processor portfolios. CCS comprises a suite of tools used to develop and debug embedded applications including an optimizing C/C++ compiler, source code editor, project build environment, debugger, profiler and many other features. CCS is available as both a desktop or cloud-based IDE.

CCS integrates MSPM0 device configuration and auto-code generation from SysConfig as well as MSPM0 code examples and academy trainings in the integrated TI Resource explorer. CCS offers an all-in-one development tool experience.

In addition to CCS, MSPM0 devices are also supported in industry-standard IDEs listed in the following table.

2.1.3 CubeMX vs SysConfig

SysConfig is an intuitive and comprehensive collection of graphical utilities for configuring pins, peripherals, radios, subsystems, and other components. It is TI's equivalent of STM32 CubeMX. SysConfig helps manage, expose, and resolve conflicts visually so that you have more time to create differentiated applications. The tool's output includes C header and code files that can be used with MSPM0 SDK examples or used to configure custom software. SysConfig is integrated into CCS but can also be used as a standalone program.

For details, refer to the MSPM0 SysConfig Guide.

2.2 Hardware Ecosystem

LaunchPad development kits are the only evaluation modules for the MSPM0. LaunchPad kits are easy-to-use EVMs that contain everything needed to start developing on the MSPM0. This includes an onboard debug probe for programming, debugging, and measuring power consumption with EnergyTrace™ technology. MSPM0 LaunchPad kits also feature onboard buttons, LEDs, and temperature sensors among other circuitry. Rapid prototyping is simplified by the 40-pin BoosterPack™ plug-in module headers, which support a wide range of available BoosterPack plug-in modules. You can quickly add features like wireless connectivity, graphical displays, environmental sensing, and more.

• LP-MSPM0G3507 LaunchPad development kit
• LP-MSPM0L1306 LaunchPad development kit

2.3 Debug Tools

The debug subsystem (DEBUGSS) interfaces the serial wire debug (SWD) two-wire physical interface to multiple debug functions within the device. MSPM0 devices support debugging of processor execution, the device state, and the power state (using EnergyTrace technology). Figure 2-3 shows the connection of the debugger.

MSPM0 support XDS110 and J-Link debugger for standard serial wire debug.

The Texas Instruments XDS110 is designed for TI embedded processors. XDS110 connects to the target board through a TI 20-pin connector (with multiple adapters for TI 14-pin and Arm 10-pin and Arm 20-pin) and to the host PC through USB2.0 High Speed (480 Mbps). It supports a wider variety of standards (IEEE1149.1, IEEE1149.7, SWD) in a single pod. All XDS debug probes support Core and System Trace in all Arm and DSP processors that feature an Embedded Trace Buffer (ETB). For details, refer to XDS110 Debug Probe.

J-Link debug probes are the most popular choice for optimizing the debugging and flash programming experience. Benefit from record-breaking flash loaders, up to 3-MiB/s RAM download speed and the ability to set an unlimited number of breakpoints in the flash memory of MCUs. J-Link also supports a wide range of CPUs and architectures included CortexM0+. For details, visit the Segger J-Link Debug Probes page.

2.4 Migration Process

The first step in migrating is to review the portfolio and choose the best MSPM0 MCU. After an MSPM0 MCU has been selected, choose a development kit. Development kits include a LaunchPad kit available for purchase and design files for a Target-Socket Board. TI also provides a free MSPM0 Software Development Kit (SDK), which is available as a component of Code Composer Studio IDE desktop and cloud version within the TI Resource Explorer. Use the peripheral sections of this application note for help with porting software from STM32 to MSPM0. Finally, once the software ported, download and debug the application with our debugging tools.

2.5 Migration and Porting Example

To become more familiar with the TI ecosystem and explain how to best get started with MSPM0, this section describes the step-by-step migration process of a basic application.

To demonstrate the process of porting from STM32 to MSPM0, this description includes the steps to port a basic low-power UART monitor application from an STM32G0x to a MSPM0 device using an existing ST UART example as the starting point.

Step 1. Chose the right MSPM0 MCU

The first step of migration is to choose the correct MSPM0 device for the application. To do this, the portfolio section of this guide can be used to choose a MSPM0 family. To narrow down to a specific device using the product selection tool. STM32G0 and MSPM0 share the M0+ core, but features such as memory size, power, and key peripherals must also be considered. MSPM0 also offers many pin-to-pin scalable options, providing the ability to easily scale to larger or smaller memory devices without changing anything else in the system.

For purposes of this example, we have chosen the MSPM0G3507 as the best fit for his application.

Step 2. Select hardware and order an EVM

Using an evaluation module (EVM) can expedite the migration process. For the MSPM0 MCUs, a LaunchPad kit is the easiest hardware to begin on. LaunchPad kits are easy to use because they come with a built-in programmer and are designed to enable rapid development.

The MSPM0G3507 has a LaunchPad development kit (LP-MSPM0G3507) that can be used for porting the software.

Step 3. Setup software IDE and SDK

Before the software can be ported, a software development environment must be chosen and setup. Section 2.1 shows all of the IDEs supported by MSPM0. The migration and porting process is similar for any IDE that is chosen. The latest version of the MSPM0 SDK should be used.

For this example, TI's CCS is the chosen IDE.

Step 4. Software porting

When the environment is ready, start using the MSPM0 SDK. As mentioned, the MSPM0 SDK is similar to the STM32Cube software package. The MSPM0 SDK offers different layers for software development. MSPM0 TI Drivers operate at a similar level to STM32Cube HAL, while MSPM0 DriverLib is comparable to the STM32Cube low-level drivers. Most MSPM0 users find DriverLib level software is the best fit for their applications, so most MSPM0 software examples are also DriverLib based. This example uses DriverLib.

One option when porting a project is to try to replace each section of code with equivalent MSPM0 DriverLib APIs, but this is not generally the easiest path. Generally, it is best to first understand the application code being ported. Then start with the closest MSPM0 example project and modify it to match the original code functionality. This process is going to be shown below using a low-power UART example from STM32CubeG0. For more complex projects using many peripherals, this process is typically repeated for each peripheral.

Step 4a: Understand the application

The following description is from the example project from STM32CubeG0 named 'LPUART_WakeUpFromStop_Init'.

@par Example Description

Configuration of GPIO and LPUART peripherals to allow characters received on LPUART RX pin to wake up the MCU from low-power mode. This example is based on the LPUART LL API. The peripheral initialization uses LL initialization function to demonstrate LL init usage.

LPUART Peripheral is configured in asynchronous mode (9600 bauds, 8 data bit, 1 start bit, 1 stop bit, no parity). No HW flow control is used. LPUART Clock is based on HSI.

Example execution:

After startup from reset and system configuration, LED3 is blinking quickly during 3 sec, then MCU enters "Stop 0" mode (LED3 off). On first character reception by the LPUART from PC Com port (ex: using HyperTerminal) after "Stop 0" Mode period, MCU wakes up from "Stop 0" Mode.

Received character value is checked:

• On a specific value ('S' or 's'), LED3 is turned On and program ends.
• If different from 'S' or 's', program performs a quick LED3 blinks during 3 sec and enters again "Stop 0" mode, waiting for next character to wake up.

The first step is to understand the main settings for the MCU. This is generally clock speeds and power policies. In this example, the general clock frequency is not specified because the only important setting is that the UART works in low power Stop0 mode. It states the low power UART clock is based on the 'HIS' or high-speed internal oscillator meaning there is no external crystal being used. The UART runs at 9600 baud, 8 data bits, 1 start and stop bit, no parity. No hardware flow control is used. The application side checks for an 'S' or 's' to be received and blinks an LED.

Step 4b: Find the closest MSPM0 example

Next step is to understand any differences between the UART modules for STM32G0 and MSPM0 and then find the closest example in the MSPM0 SDK. This is easily accomplished by referring to the UART section in Section 4. This section highlights differences between the UART modules and links to the UART-related MSPM0 SDK code examples. The closest example in the SDK for this example is probably uart_echo_interrupts_standby where the "UART RX/TX echos using interrupts while device is in STANDBY mode".

This MSPM0 example is similar, but not identical to the being ported. This example is going to standby mode, which is a lower power mode than Stop mode. The UART communication settings must be checked as well as which GPIOs are being used. Finally, the application layer of monitoring for a specific character must be added.

Step 4c: Import and modify the example

Once a similar example is found, Open CCS and import the code example by going to Project > Import CCS Projects... and navigate it to the MSPM0 SDK example folder. Import the example. Here is the uart_echo_interrupts_standby example imported. This is a SysConfig project, so the main C file is simple. It first calls the SysConfig driverlib initialization which is a function autogenerated by SysConfig to configures the device. Then it enables the UART interrupt. Finally it goes to sleep waiting for any UART transaction. If it receives a UART transaction, it echos the data right back and wakes up.

To see the SysConfig configuration, open the .syscfg file, which opens on the SYSCTL tab by default. For detailed guide on using SysConfig, see the SysConfig Guide in the in the MSPM0 SDK.

The first thing to note is the power policy. This MSPM0 example is using Standby0 mode but the goal is to use Stop0 mode. By clicking the drop-down list, the correct low-power mode can be chosen. All of the clocks and oscillators can be configured on this tab as well, but are fine for now.

Next, check the UART communication settings on the UART tab (see Figure 2-8). In this case, the baud rate is already set to 9600 and the rest of communication settings are correct. The receive interrupt is already enabled and used in the main program. Also check the UART module and pins being used by clicking the chip icon in the top right and checking the highlighted pins for the UART. Nothing here needs to be changed as these are already connected to the MSPM0G3507 LaunchPad kit's backchannel UART.

This example currently has no GPIOs configured for driving an LED, but the configuration can be added easily (see Figure 2-9). A GPIO can be added by using the +ADD button at the top of the page. The GPIO port and pin can be named, in this case 'LED' and 'RED' respectively. This GPIO is set as an output and then put on Port A pin 0 (PA0.) On the LaunchPad kit, this GPIO is tied to a simple red LED.

When the project is saved and rebuilt, SysConfig updates the ti_msp_dl_config.c and ti_msp_dl_config.h files for the example. At this point, the example hardware configuration has been modified to match the full functionality of the original software being ported. The only remaining effort is application-level software to check the incoming UART bytes and toggle the LED. This is accomplished by moving over a small amount of code into the main C file.

Figure 2-10. Changes to Application Code

Two changes are made to the application code. First, DL_SYSCTL_disablesSleepOnExit() is used so that the MSPM0 wakes briefly on each UART RX. Next, a simple check of the UART RX data is added, and if an 'S' or 's' is received, the red LED is turned on. Anything else and it is turned off.

Step 5: Debug and verify

The following figures are captures from an logic analyzer showing the UART communication at 9600 baud and the red LED being turned on and off correctly. The code is echoing every UART character but only turning on the LED when the correct character is received.

The software has successfully been ported! If this was just the first peripheral of many, continue to repeat this process and use SysConfig to combine each block.

3 Core Architecture Comparison

3.1 CPU

The STM32G0 and MSPM0 family of parts are both based on the Arm Cortex® M0+ CPU core architecture and instruction set. The table below gives a high-level overview of the general features of the CPUs in the MSPM0G and MSPM0L families compared to the STM32G0. Interrupts and Exceptions provides a comparison of the interrupts and exceptions and how they are mapped in the Nested Vectored Interrupt Controller (NVIC) peripheral included in the M0 architecture for each device.

(1) Refer to the device-specific data sheet for availability.

(2) Other interfaces to be made available in later device releases.

3.2 Embedded Memory Comparison

3.2.1 Flash Features

The MSPM0 and STM32G0 family of MCUs feature nonvolatile flash memory used for storing executable program code and application data.

In addition to the flash memory features listed in the previous table, the MSPM0 flash memory also has the following features:

• In-circuit program and erase supported across the entire supply voltage range
• Internal programming voltage generation
• Support for EEPROM emulation with up to 100 000 program/erase cycles on the lower 32KB of the flash memory, with up to 10000 program/erase cycles on the remaining flash memory (devices with 32KB support 100 000 cycles on the entire flash memory)

3.2.2 Flash Organization

The flash memory is used for storing application code and data, the device boot configuration, and parameters that are preprogrammed by TI from the factory. The flash memory is organized into one or more banks, and the memory in each bank is further mapped into one or more logical memory regions and assigned system address space for use by the application.

Memory Banks

Most MSPM0 devices implement a single flash bank (BANK0). On devices with a single flash bank, an ongoing program/erase operation stalls all read requests to the flash memory until the operation has completed and the flash controller has released control of the bank. On devices with more than one flash bank, a program/erase operation on a bank also stalls read requests issued to the bank that is executing the program/erase operation but does not stall read requests issued to another bank. Therefore, the presence of multiple banks enables application cases such as:

• Dual-image firmware updates (an application can execute code out of one flash bank while a second image is programmed to a second symmetrical flash bank without stalling the application execution)
• EEPROM emulation (an application can execute code out of one flash bank while a second flash bank is used for writing data without stalling the application execution)

Flash Memory Regions

The memory within each bank is mapped to one or more logical regions based upon the functions that the memory in each bank supports. There are four regions:

• FACTORY – Device Id and other parameters
• NONMAIN – Device boot configuration (BCR and BSL)
• MAIN - Application code and data
• DATA - Data or EEPROM emulation

Devices with one bank implement the FACTORY, NONMAIN, and MAIN regions on BANK0 (the only bank present), and the data region is not available. Devices with multiple banks also implement FACTORY, NONMAIN, and MAIN regions on BANK0, but include additional banks (BANK1 through BANK4) that can implement MAIN or DATA regions.

3.2.3 Embedded SRAM

The MSPM0 and STM32G0 family of MCUs feature SRAM used for storing application data.

MSPM0 MCUs include low-power high-performance SRAM with zero wait state access across the supported CPU frequency range of the device. SRAM can be used for storing volatile information such as the call stack, heap, and global data, in addition to code. The SRAM content is fully retained in run, sleep, stop, and standby operating modes, but is lost in shutdown mode. A write protection mechanism is provided to allow the application to dynamically write protect the lower 32KB of SRAM with 1KB resolution. On devices with less than 32KB of SRAM, write protection is provided for the entire SRAM. Write protection is useful when placing executable code into SRAM as it provides a level of protection against unintentional overwrites of code by either the CPU or DMA. Placing code in SRAM can improve performance of critical loops by enabling zero wait state operation and lower power consumption.

3.3 Power Up and Reset Summary and Comparison

Similar to STM32G0 devices, MSPM0 devices have a minimum operating voltage and have modules in place to make sure that the device starts up properly by holding the device or portions of the device in a reset state. Table 3-4 shows a comparison on how this is done between the two families and what modules control the power up process and reset across the families.

(1) Not all reset triggers described. Refer to the PMCU chapter of the device TRM for all available reset triggers.

(2) If BOOTRST cause was through NRST or software trigger, RTC, LFCLK, and LFXT/LFLCK_IN configurations and IOMUX settings are NOT reset to allow RTC to maintain operation through external reset.

3.4 Clocks Summary and Comparison

STM32G0 and MSPM0 contain internal oscillators which source primary clocks. The clocks can be divided to source other clocks and be distributed across the multitude of peripherals.

(1) SYSOSC is programmable to be 32 MHz, 24 MHz, 16 MHz, or 4 MHz.

(1) SYSPLLCLK2x is twice the speed of the output of the PLL module and can be divided down.

(2) BUSCLK depends on the Power Domain. For Power Domain 0, BUSCLK is ULPCLK. For Power Domain 1, BUSCLK is MCLK.

The TRM for each device family has a clock tree to help visualize the clock system. Sysconfig can assist with the options for clock division and sourcing for peripherals.

3.5 MSPM0 Operating Modes Summary and Comparison

MSPM0 MCUs provide five main operating modes (power modes) to allow for optimization of the device power consumption based on application requirements. In order of decreasing power, the modes are: RUN, SLEEP, STOP, STANDBY, and SHUTDOWN. The CPU is active executing code in RUN mode. Peripheral interrupt events can wake the device from SLEEP, STOP, or STANDBY mode to the RUN mode. SHUTDOWN mode completely disables the internal core regulator to minimize power consumption, and wake is only possible via NRST, SWD, or a logic level match on certain IOs. RUN, SLEEP, STOP, and STANDBY modes also include several configurable policy options (for example, RUN.x) for balancing performance with power consumption.

To further balance performance and power consumption, MSPM0 devices implement two power domains: PD1 (for the CPU, memories, and high performance peripherals), and PD0 (for low speed, low power peripherals). PD1 is always powered in RUN and SLEEP modes, but is disabled in all other modes. PD0 is always powered in RUN, SLEEP, STOP, and STANDBY modes. PD1 and PD0 are both disabled in SHUTDOWN mode.

MSPM0 Capabilities in Lower Power Modes

As seen in Table 3-9, MSPM0 peripherals or peripheral modes can be limited in availability or operating speed in lower power operating modes. For specific details, see the "Supported Functionality by Operating Mode" table found in the MSPM0 device-specific data sheet, for example:

• MSPM0G350x Mixed-Signal Microcontrollers data sheet
• MSPM0L134x, MSPM0L130x Mixed-Signal Microcontrollers data sheet

An additional capability of the MSPM0 devices is the ability for some peripherals to perform an Asynchronous Fast Clock Request. This allows MSPM0 device to be in a lower power mode where a peripheral is not active, but still allow a peripheral to be triggered or activated. When an Asynchronous Fast Clock Request happens, the MSPM0 device has the ability to quickly ramp up an internal oscillator to a higher speed and/or temporarily go into a higher operating mode to process the impending action. This allows for fast wake up of the CPU from timers, comparator, GPIO, and RTC; receive SPI, UART, and I2C; or trigger DMA transfers and ADC conversions, while sleeping in the lowest power modes. For specific details on implementation of Asynchronous Clock Requests as well as peripheral support and purpose, see the appropriate chapter in the MSPM0 TRMs.

MSPM0 G-Series 80-MHz Microcontrollers Technical Reference Manual

MSPM0 L-Series 32-MHz Microcontrollers Technical Reference Manual

Entering Lower-Power Modes

Like STM32G0 devices, the MSPM0 devices go into a lower-power mode when executing the wait for event, WFE();, or wait for interrupt, WFI();, instruction. The low-power mode is determined by the current power policy settings. The device power policy is set by a driver library function. The following function call sets that power policy to Standby 0.

DL_SYSCTL_setPowerPolicySTANDBY0();

STANDBY0 can be replaced with the operating mode of choice. For a full list of driverlib APIs that govern power policy, see this section of the MSPM0 SDK DriverLib API guide. Also see the following code examples that demonstrate entering different operating modes. Similar examples are available for every MSPM0 device.

Low-power mode code examples

Navigate to the SDK installation and find low-power mode code examples in examples > nortos > LP name > driverlib

3.6 Interrupt and Events Comparison

Interrupts and exceptions

The MSPM0 and STM32G0 both register and map interrupt and exception vectors depending on the device's available peripherals. A summary and comparison of the interrupt vectors for each family of devices is included in Table 3-10. A lower value of priority for an interrupt or exception is given higher precedence over interrupts with a higher priority value. For some of these vectors the priority is user-selectable, and for others it is fixed. In the MSPM0 and STM32G0, exceptions such as NMI, reset, and hard fault handlers are given negative priority values to indicate that they always have the highest precedence over peripheral interrupts. For peripherals with selectable interrupt priorities, up to 4 programmable priority levels are available on both families of devices.

(1) Only available in MSPM0G family of devices.

(2) TIMG4 on MSPM0L family of devices

Event Handler and EXTI (Extended Interrupt and Event Controller)

The MSPM0 devices include a dedicated event manager peripheral, which extends the concept of the NVIC to allow digital events from a peripheral to be transferred to the CPU as interrupts, to the DMA as a trigger, or to another peripheral to trigger a hardware action. The event manager can also perform handshaking with the power management and clock unit (PMCU), to make sure that the necessary clock and power domain are present for triggered event actions to take place.

In the MSPM0 event manager, the peripheral that generates the event is known as a publisher, and the peripheral, DMA, or CPU that acts based on the publisher is known as the subscriber. The potential combinations of available publisher and subscriber are extremely flexible and can be used when migrating software to replace functionality previously handled by interrupt vectors and the CPU, to bypass the CPU entirely. For example, an I2C-to-UART bridge may previously have triggered a UART transmission upon receipt of an I2C STOP, using an ISR to set a flag, or load the UART TX buffer directly. With the MSPM0 Event handler, the I2C transaction complete event could trigger the DMA to load the UART TX buffer directly, and therefore eliminate the need for any action by the CPU.

3.7 Debug and Programming Comparison

The Arm SWD 2-wire JTAG port is the main debug and programming interface for both MSPM0 and STM32G0 devices. This interface is typically used during application development, and during production programming. Table 3-11 compares the features between the two device families. For additional information about security features of the MSPM0 debug interface, see the Cybersecurity Enablers in MSPM0 MCUs application note.

(1) MSPM0Gxxxx devices only

Bootstrap Loader (BSL) Programming Options

The bootstrap loader (BSL) programming interface is an alternative programming interface to the Arm SWD. This interface offers programming capabilities only, and typically is utilized through a standard embedded communication interface. This allows for firmware updates through existing connections to other embedded devices in system or external ports. Although programming updates is the main purpose of this interface, it can also be utilized for initial production programming as well. Table 3-12 shows a comparison of the different options and features between MSPM0 and STM32G0 device families.

(1) Pattern option availability is device dependent.

(2) Only on select devices

4 Digital Peripheral Comparison

4.1 General-Purpose I/O (GPIO, IOMUX)

MSPM0 GPIO functionality covers virtually all the features provided by STM32G0 GPIO. STM32G0 uses the term GPIO to refer to all the functionality responsible for managing the device pins. However, MSPM0 uses a slightly different nomenclature, namely:

• MSPM0 GPIO refers to the hardware capable of reading and writing IO, generating interrupts, etc.
• MSPM0 IOMUX refers to the hardware responsible for connecting different internal digital peripherals to a pin. IOMUX services many different digital peripherals including, but not limited to, GPIO.

Together MSPM0 GPIO and IOMUX cover the same functionality as STM32G0 GPIO. Additionally, MSPM0 offers functionality not available in STM32G0 devices such as DMA connectivity, controllable input filtering and event capabilities.

GPIO code examples

Information about GPIO code examples can be found in the MSPM0 SDK examples guide.

4.2 Universal Asynchronous Receiver-Transmitter (UART)

STM32G0 and MSPM0 both offer peripherals to perform asynchronous (clockless) communication. These UART peripherals come in two variants, one with standard features and one with advanced features. The naming differences are shown in Table 4-2.

(1) Requires reconfiguration of the peripheral between transmission and reception

(1) Requires reconfiguration of the peripheral between transmission and reception

UART code examples

Information about UART code examples can be found in the MSPM0 SDK examples guide.

4.3 Serial Peripheral Interface (SPI)

MSPM0 and STM32G0 both support serial peripheral interface (SPI). Overall, MSPM0 and STM32G0 SPI support is comparable with the difference listed in Table 4-5.

SPI code examples

Information about SPI code examples can be found in the MSPM0 SDK examples guide.

4.4 I2C

MSPM0 and STM32G0 both support I2C. Overall MSPM0 and STM32G0 I2C support is comparable with notable difference outlined in the following table.

I2C code examples

Information about I2C code examples can be found in the MSPM0 SDK examples guide.

4.5 Timers (TIMGx, TIMAX)

STM32G0 and MSPM0 both offer various timers. MSPM0 offers timers with varying features that support use cases from low power monitoring to advanced motor control.

Timer code examples

Information about timer code examples can be found in the MSPM0 SDK examples guide.

4.6 Windowed Watchdog Timer (WWDT)

STM32G0 and MSPM0 both offer Window Watchdog Timers. The window watchdog timer (WWDT) initiates a system reset when the application fails to check-in during a specified window in time.

WWDT code examples

Information about WWDT code examples can be found in the MSPM0 SDK examples guide.

4.7 Real-Time Clock (RTC)

STM32G0 and MSPM01 both offer a real-time clock (RTC). The real-time clock (RTC) module provides time tracking for the application, with counters for seconds, minutes, hours, day of the week, day of the month, and year, in selectable binary or binary-coded decimal format.

1 Only MSPM0G devices support RTC.

RTC code examples

Information about RTC code examples can be found in the MSPM0 SDK examples guide.

5 Analog Peripheral Comparison

5.1 Analog-to-Digital Converter (ADC)

STM32G0 and MSPM0 both offer ADC peripherals to convert analog signals to a digital equivalent. Both device families feature a 12-bit ADC. The following tables compare the different features and modes of the ADCs.

(1) ADC can be triggered in standby mode, which changes the operating mode.

(2) The number of external input channels varies per device.

(3) The number of ADCs varies per device.

ADC code examples

Information about ADC code examples can be found in the MSPM0 SDK examples guide.

5.2 Comparator (COMP)

The STM32G0 and MSPM0 family of parts both offer integrated comparators as optional peripherals on some devices. In both families of devices these are denoted as COMPx, where the 'x' final character refers to the specific comparator module being considered. In the STM32G0 family these are numbered 1-3, and in the MSPM0 family these are numbered 0-2. The comparator modules can both provide a windowed comparator functionality in devices with more than 1 comparator, can take inputs from various internal and external sources, and can be used to trigger changes in power mode or truncate/control PWM signals. A summary of how the MSPM0 and STM32G0 comparator modules compare feature-by-feature is included in Table 5-3.

(1) Only on devices with DAC12 peripheral

(2) Only on devices with OPA1 peripheral

(3) Only on devices with OPA0 peripheral

COMP code examples

Information about COMP code examples can be found in the MSPM0 SDK examples guide.

5.3 Digital-to-Analog Converter (DAC)

The STM32G0 and MSPM0 family of parts both offer 12-bit DAC peripherals to perform digital to analog conversion for various applications. In the STM32G0 documentation, this peripheral is referred to just as the DAC. In the MSPM0 Technical Reference Manual, the MSPM0 series data sheets, and the MSPM0 SDK, the 12-bit DAC peripheral is referred to as the DAC12. This differentiates the DAC12 from the 8-bits DACs which are available for use with each comparator peripheral included in a given MSPM0 device. Those additional 8-bit DACs are covered in the comparator section of this document. This DAC12 peripheral is only available on the MSPM0G family of devices.

The features of the 12-bit DAC peripherals for the STM32G0 and MSPM0G are summarized in Table 5-4.

(1) Available only on some devices.

(2) Dual DAC channels are planned for future MSPM0G devices.

DAC12 code examples

Information about DAC12 code examples can be found in the MSPM0 SDK examples guide.

5.4 Operational Amplifier (OPA)

The STM32G0 family of devices does not offer an integrated Operational Amplifier (OPA) peripheral, but when migrating from the STM32G0 to MSPM0 family, you can make use of the MSPM0 internal OPAs to replace external discrete devices, or to buffer internal signals as necessary. The MSPM0 OPA modules are completely flexible, and can individually, or in combination, replace many discrete amplifiers in sensing or control applications. The primary features of the MSPM0 OPA modules are included in Table 5-5, and examples of common OPA configurations you can recreate are included in OPA code examples

OPA code examples

Information about OPA code examples can be found in the MSPM0 SDK examples guide.

5.5 Voltage References (VREF)

The STM32G0x and MSPM0 both have internal references which can be used to supply a reference voltage to internal peripherals and output to external peripherals.

For the MSPM0 VREF, you must enable the power bit, PWREN Bit0 (ENABLE).

VREF code examples

Code examples that use VREF can be found in the MSPM0 SDK examples guide.

6 Revision History

NOTE: Page numbers for previous revisions may differ from page numbers in the current version.