• Locked Locked
  • Replies 41 replies
  • Subscribers 98 subscribers
  • Views 183720 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ] MSP432 SimpleLink MCU FAQ

Dung Dang
Genius 17802 points
Other Parts Discussed in Thread: ENERGYTRACE, MSP-TS432PZ100, SEGGER, CC2650, MSP430F5529, MSP430FG4619, UNIFLASH

Hi everyone,

this FAQ addresses the most common questions one might have about the new MSP432™ MCU. The main topics currently covered in this FAQs are:

  • MSP432 MCU Overview
  • List of MSP432 microcontroller resources
  • Key features of MSP432 MCU
  • More MSP432 MCU technical details
  • MSP432 Microcontroller Tools, IDE & Debug
  • MSP432 Microcontroller LaunchPad
  • EnergyTrace™ Software and Technology
  • TI Cloud Development Tools

IMPORTANT VERSION INFORMATION for Rev. C devices and Red MSP-EXP432P401R Launchpads
If you are using Rev. C MSP432 microcontrollers, there are minimum version requirements for CCS, IAR, Keil and SimpleLink™ MSP432 software development kit (SDK). Please see www.ti.com/xms432support and the app note Moving From Evaluation to Production With MSP432P401x MCUs for more information.

 

MSP432 MCU Overview

Q: What is Texas Instruments announcing?
A: TI is announcing an expanded MSP portfolio including a new family of 32‐bit processors built on the ARM Cortex‐M4F core. The first family includes the MSP432P401x MCUs with 48MHz speed, 1MSPS 14‐bit ADC, up to 256KB flash, up to 64kB RAM and low‐power operation of only 95uA/MHz active and 850nA in standby with RTC. 

Q: What is MSP?
A: MSP is TI’s low‐power MCU portfolio. It includes two platforms: 16‐bit ultra‐low‐power MSP430™ MCUs and 32‐bit low power and performance MSP432 MCUs.

Q: Why is TI moving its MSP430 MCU family from a proprietary core to an industry‐standard core?
A: The 16‐bit MSP430 MCUs are on a TI‐developed (proprietary) core and will continue to be developed and produced for all of our customers needing ultra‐low power MCUs. The new MSP432 MCU family is designed for customers who care about low‐power consumption, but need added performance (32‐bits and 48MHz) or are looking to take, or already have taken, their designs to the industry‐standard ARM Cortex‐M core.

Q: Is TI changing its focus for MSP430 towards performance instead of low‐power?

A: No. Low‐power remains at the heart of MSP’s brand, expertise and value proposition to our customers. The MSP architecture is optimized for low‐power; however the new MSP432 MCU platform will also include high performance features.

Q: Where does the MSP432 MCU platform fit within TI’s MCU portfolio, within the MSP MCU portfolio?

A: The MSP432 MCU platform is part of the TI’s low‐power MSP MCU portfolio. Within MSP, MSP432 MCUs are part of the “Low‐Power + Performance” family (which also includes the 16‐bit MSP430F5x/F6x series). MSP also contains the “Ultra‐Low Power” family that includes TI’s FRAM MCU products and the “Security + Communication” family that includes RF430 SoCs with an integrated 13.56MHz RF radio.

Q: Why is TI using an ARM Cortex‐M4F core in its MSP MCU portfolio?

A: TI’s MSP432 MCUs are a differentiated low‐power Cortex‐M‐based MCU that provide performance benefits to existing MSP430 customers and enable existing ARM developers to become part of the MSP family. With more than 20 years of low‐power expertise, TI’s MSP MCU team is best equipped to create a low‐power general purpose Cortex–M solution with a focus on high performance, analog integration and ease of use. MSP is recognized as a trusted, low‐power leader with an ecosystem that enables developers of all experience levels.

Q: What is the SDK?

A: The MSP432 software development kit (SDK) is a comprehensive software package that enables engineers to quickly develop highly functional applications on Texas Instruments MSP432 microcontrollers (MCUs). The MSP432 SDK is comprised of multiple compatible software components including RTOS, drivers, and middleware as well as examples of how to use these components together. In addition, examples are provided to demonstrate the use of each functional area and each supported device and as a starting point for your own projects.

Q: What is a plug-in?

A: Plugins are intended to extend functionality of each individual base SDK to include specialized use-cases. These specialized use cases can range anywhere from adding wireless functionality to extending a base SDK's example base.

While all of the plugins have the same basic structure and look-and-feel of an SDK, they are not meant as standalone applications and rely heavily on components from the base SDK. The SimpleLink MSP432 SDK Bluetooth Plugin, for example, relies heavily on the TI-Drivers, TI-RTOS, DriverLib, and GraphicsLib components from the base SDK. A high level block diagram of these dependencies can be seen in the image below:

List of MSP432 Resources

For more information on the MSP432 MCU device, go to:

 

 Key features of MSP432 MCUs

Q: What new features are available on MSP432 MCUs?

A: The MSP432 microcontroller is designed for customers looking for high performance, analog integration or general purpose processing. Key features within the MSP432 MCU portfolio include a 48MHz ARM Cortex‐M4F core with floating point unit (FPU); Driver Lib in‐ROM; wide voltage range from 1.62‐3.7 V; simultaneous flash read/write; 128‐bit flash buffer and pre‐fetch; selectable RAM retention; 64 KB RAM, 1MSPS ADC14; 8‐ channel DMA; memory protection unit; integrated LDO and DC/DC; NVIC with tail‐chaining; tunable DCO; peripheral and SRAM memory bit‐band; 20mA high drive I/O; 32‐bit timer; JTAG security and advanced IP protection; UART; I2C; SPI Bootstrap Loader and TI’s EnergyTrace+™ Technology.
 
Q: Can MSP432 MCUs operate at full speed across the entire voltage range (1.62 – 3.7V)?

A: Yes. MSP432 MCUs can operate up to 48MHz across the entire voltage range, even at the minimum supply voltage of 1.62V. Flash access is also available at 1.62V.
 
Q: What wakeup options from LPM3 are available from MSP432 MCUs?

A: MSP432 MCUs offer wakeup from LPM3 via the RTC, WDT and GPIOs. This is to ensure current consumption is minimized in LPM3, by gating the rest of the peripherals. As a result, TI was able to achieve 850nA in LPM3. TI is working on future MSP432 MCUs that offer wake-up capabilities from additional interfaces and peripherals.
 
Q: What is ULPBench™?

A: ULPBench is an ultra‐low power benchmark (ULPBench) from the Embedded Microprocessor Benchmark Consortium (EEMBC), who developed the CoreMark standard for evaluating processor performance across architectures. Similarly, ULPBench provides a standard way to compare power performance on any MCU, independent of architecture. The new MSP432 MCUs are the latest advancement in TI’s ultra‐low‐power innovation, delivering a best‐in‐class ULPBench score of 192.3 – outperforming all other Cortex‐M3 and Cortex‐M4F MCUs on the market.
 
Q: How does ULPBench evaluate MCUs for a ULP application?

A: The ULPBench benchmark from EEMBC includes considerations of power modes, usage of a real-time clock or timer-triggered wakeup, and a standardized computational workload, which provide a great starting point for comparing application-level power consumption across microcontrollers. That said, it includes a single application use-case and further analysis is required to evaluate microcontrollers in your specific application, which may require a different active/low power mode duty cycle than that provided by the benchmark. TI’s FRAM MCU portfolio and MSP432 MCU platform each deliver a unique set of benefits that customers can leverage in their applications – focusing on performance and/or low-power. EEMBC’s EnergyMonitor tool can be leveraged in your application to measure power consumption over time and can even be used for power-debugging once the right microcontroller is selected for an application.
 
Q: Why does TI have a new part numbering scheme for MSP432 MCUs?

A: MSP430 MCUs have unmatched brand recognition worldwide. TI worked to retain much of the original MSP430 naming; however it changed the ‘430’ to ‘432’ to reflect the new 32‐bit performance capability. The next digit in the part number indicates the series – ‘P’ meaning “Low power + Performance” series. The next digit indicates the family – the first of which in the ARM Cortex‐M4F portfolio is to the ‘4’ family. The full MSP432 MCU part numbering scheme is available online.
 
Q: How can I begin evaluating new MSP432 MCUs?

A: Start evaluating MSP432 MCUs immediately with a target board (MSP‐TS432PZ100) or a low‐cost LaunchPad rapid prototyping kit (MSP‐EXP432P401R) with on‐board emulation. Both kits are available from the TI Store.
 
Q: Where can I learn about MSP432 MCU? Is there any training or workshop that I can attend?

A: There is training and application notes available for MSP432 MCU.
For training & workshops go to:
For MSP432 MCU Application Notes go to:

More MSP432 Technical Details

Q: Does the MSP432 microcontroller require a 48Mhz external crystal or can it run directly from the DCO?  What are the tradeoffs?
 
A: MSP432 can use either the internal DCO or an external crystal, both up to 48MHz. The internal DCO has +/-3% tolerance, though you can use a high precision external resistor to improve the DCO tolerance to +/-0.6%. External crystal will give you higher precision, with the tradeoff possibly being higher cost.
 
Q: How will CMSIS be supported on MSP432P4xx MCU?

A: MSP432 header file includes both MSP & CMSIS definitions as well as CMSIS intrinsics & core functions. CMSIS DSP libraries are also fully compatible with MSP432 MCU.
 
Q: What peripheral interfaces will be supported on the MSP432 BSL?

A: The default MSP432 MCU Flash BSL supports the UART, I2C and SPI peripheral interfaces (unlike previous BSL versions that only supported one peripheral interface).  The command structure is the same as previous MSP430 MCU BSLs.
 
Q: Can the BSL be disabled?

A: BSL is flash-based BSL similar to MSP430 MCU (5xx/6xx). You can customize the BSL, or you can permanently disable it by erasing the BSL memory.
 
Q: What’s the definition of IP Security on MSP432P4xx MCU?

A: One of the most important functions of the SYSCTL module is the security control of the device. MSP432 microcontrollers are capable of securing the devices against access from the debugger (Full chip security) similar to MSP430 MCU. In addition, MSP432 controllers provide security control for different configurable regions of the device. Application can choose to load a secure code (IP software/middleware) into the device Flash memory. There are 4 IP-protected regions with executable IP blocks that are protected from read/write access. Encrypted field firmware update is supported for IP protection regions.
 
Q: How do you secure JTAG on MSP432P4xx MCU?

All JTAG (debugger) accesses to secure memory zones are treated as unauthorized and also return an error response. The feature is available via IDE or as part of your application to completely block future application JTAG accesses to the device. After locking the JTAG, only BSL access is possible. Device is only recoverable after a complete device erase removing all data & secure information on the device.
 
Q: How many banks of Flash are on the MSP432 microcontrollers with 256kB Flash & 64kB SRAM?

A: 2 banks, each with 128kB and consisting of 32 x  4kB sectors.
 
Q: How many banks of SRAM are on the MSP432 microcontrollers with 256kB Flash & 64kB SRAM?

A: 8 banks, each with 8kB.
 
Q: What portions of SRAM are retained in low power modes?
 
A: Bank 0 of SRAM is always retained and cannot be powered down. Therefore, it also operates up as a possible backup memory in the LPM3, LPM4, and LPM3.5 modes of operation. In the case of LPM3 and LPM4 modes the full 8KB of SRAM bank 0 is retained but in the case of LPM3.5 mode only 6KB of SRAM bank 0 is retained. The 2KB of SRAM bank 0 over the address range 0x2000_0000 to 0x2000_007FF is not retained in LPM3.5 mode.
 
Q-a: What is the consumption when there is no code in the MSP432 flash (after a full erase)?
Q-b: What is in MSP432 MCU flash when shipped to customers? What code runs at start up when received from TI shipment?

A: For both questions: MSP432 microcontrollers (flash) are fully erased when shipped to customers. When the flash is empty (specifically when the reset vector + SP are empty), boot code automatically puts the device in BSL mode. If there’s no BSL activity after some time, device automatically goes into LPM4.5 mode, consuming <100nA.
 
Q: Where can I find the MSP432 CAD symbols?
 
A: In the product page, under Quality and Packaging.

MSP432 Tools, IDE & Debugging FAQs

Q: What is the code size limit for MSP432 MCUs in CCS?

A: When using the TI compiler, the CCS code size limit is 32kB for MSP432 MCUs. The limit is independent of the debugger used in the system (stand-alone or on-board debugger such as the MSP432 Microcontroller LaunchPad). There is no code size limit when using the ARM GCC Compiler inside CCS. You can download/update TI as well as ARM GCC compilers from the CCS App Center.
 
Q: Which debuggers can I use to debug MSP432 MCUs?

An updated list can be found here.  If you are using the MSP-EXP432P401R LaunchPad, you can use the XDS110-ET on-board emulator.
  • In CCS, select the XDS110 USB Debug probe.
  • In IAR or Keil, select the CMSIS-DAP, or TI XDS debug probe.

If you are using the MSP-TS432PZ100 target socket board or develop your own MSP432 Microcontroller application, or just want to use an external debugger with the MSP-EXP432P401R LaunchPad, you can use one of the following debuggers.

Debugger
CCS
IAR
Keil
TI XDS200, XDS100v2, XDS100v3
✓
✓
Segger J-Link
✓
✓
✓
IAR I-jet
✓
Keil uLink2/Pro
✓
XDS110-ET (on-board LaunchPad)
✓
✓
✓
MSP430 MCU Flash Emulation Tool
✓
✓
 

Q: I can’t program my LaunchPad; the IDE can’t connect to target. What’s wrong?

A: See the FAQ section in the Launch Pad User’s Guide.  See also this E2E discussion.
 
Q: Why doesn’t the back-channel UART on the MSP432 LaunchPad work with my serial terminal program at speeds faster than 56,000 baud?

A: Certain serial terminal programs such as HTerm or the CCS built-in terminal might not work with the MSP432 LaunchPad at specific baudrates, resulting in the software not being able to open the virtual COM port or in the baud rate getting configured incorrectly. An issue with the LaunchPad’s emulator firmware has been identified and will be fixed in the next release. Until the update is available, use Tera Term, ClearConnex, or HyperTerminal instead or reduce the baud rate to speeds of 38,400 baud or lower.
 
Q: Problems plugging the MSP432 LaunchPad into a USB3.0 Port

A: It has been observed that when the MSP432 LaunchPad is connected to USB3.0 ports provided by a certain combination of USB3.0 host controller hardware and associated device drivers that the IDE is unable to establish a debug session with the LaunchPad, resulting in an error message like “CS_DAP_0: Error connecting to the target: (Error -260 @ 0x0) An attempt to connect to the XDS110 failed.” in the case of Code Composer Studio. In this case the CCS-provided low-level command line utility ‘xdsdfu’ will also not be able to establish a connection with the LaunchPad.
Specifically, this issue was observed on PCs running Windows 7 that show the “Renesas Electronics USB 3.0 Host Controller” and the associated “Renesas Electronics USB 3.0 Root Hub” in the device manager. After updating the associated Windows USB drivers to more recent versions obtained from the hardware vendor the issue went away. There might be other USB3.0 hardware and device driver combinations that will lead to the same issue. If you think you might be affected try contacting your PC vendor or try locating and installing more recent versions of the USB3.0 device drivers. Alternatively, connect the LaunchPad to an USB2.0 port on your PC if available.
 
Q: I can’t get the backchannel UART to connect. What’s wrong?

A: Check the following:
  • Do the baud rate in the host’s terminal application and the USCI settings match?
  • Are the appropriate jumpers in place, on the isolation jumper block?
  • Probe on RXD and send data from the host. If you don’t see data, it might be a problem on the host side.
  • Probe on TXD while sending data from the MSP432. If you don’t see data, it might be a configuration problem with the USCI module.
  • Consider the use of the hardware flow control lines (especially for higher baud rates).
Q: What is TI’s EnergyTrace+ technology?

A: EnergyTrace+ technology for MSP432 MCUs is an energy‐based code analysis tool that measures and displays the application’s energy profile and helps to optimize it for ultra‐low‐power consumption. This technology provides developers with a real‐time tool that monitors power consumption data within ±2 percent accuracy.

Q: Will TI expand support for its Grace™ software?

A: Grace is a tool that allows 16‐bit MSP430 developers to generate peripheral set‐up code within minutes. Alternatively, MSP432 MCUs will support the PinMux tool, which is a utility that allows developers to configure the functionality of the MSP432 MCU port pins via a graphical user interface.

MSP432 LaunchPad FAQs

Q: Can developers use existing BoosterPacks with the MSP432 Microcontroller LaunchPad?

A: Yes. TI is also adding support for existing BoosterPacks to work with the new MSP432 LaunchPad, including the CC3100 Wi-Fi BoosterPack, BLE BoosterPack  from Anaren, TRF7979A NFC BoosterPack, Kentec QVGA Display BoosterPack, Fuel Tank battery BoosterPack , the Sharp96 Display BoosterPack, and the CC2650 BoosterPack.
 
 Q: So the onboard emulator is really open source? And I can build my own onboard emulator?

A: Yes!  We encourage you to do so. The design files are on ti.com.
 
Q: The MSP430 MCU G2 LaunchPad had a socket, allowing me change the target device. Why doesn’t this LaunchPad use one?  
 
A: This LaunchPad provides more functionality, and this means using a device with more pins. Sockets for devices with this many pins are too expensive for the LaunchPad’s target price.
 
Q:  With the female headers on the bottom, the board doesn’t sit flat on the table, and I can’t unsolder them. Why did TI do this?

A: For several reasons. A major feedback item on previous LaunchPads was the desire for female headers instead of male ones. But simply using female instead is problematic, because compatibility with existing BoosterPacks would be lost, and some people prefer male headers. So, adding female headers without removing male ones satisfies both preferences. It also allows more flexibility in stacking BoosterPacks and other LaunchPads.

The down side to this approach is perhaps that the board doesn’t sit flat. But while a USB cable is attached (the usual development model), it tends to not sit flat anyway. For those wishing it to sit flat, holes were drilled in the corners, so that standoffs could be fastened. Rubber bumper feet also should work.

EnergyTrace Technology FAQs

Q: What is the sampling frequency of EnergyTrace+ technology?
 
A: The sampling frequency depends on the debugger and the selected debug protocol and its speed setting. It typically ranges from 1 kHz (for example, when using the XDS110 SWD interface) up to 3.2 kHz (for example, when using the JTAG interface set to FAST). The debugger polls the state information of EnergyTrace+ from the device status information. Depending on the sampling frequency, a short or fast duty cycle active peripheral state may not be captured on the State graph. In addition, the higher sampling frequency affects the device energy consumption under EnergyTrace.
 
Q: What is the sampling frequency of EnergyTrace technology? 

A: The sampling frequency to measure the energy consumption is the same independent of which debug protocol or speed and is approximately 4.2 kHz in Free Run mode.
 
Q: My Power graph seems to include noise. Is my board defective?
 
A: The power values shown in the Power graph are derived (that is, calculated) from the accumulated energy counted by the measurement system. When the target is consuming little energy, a small number of energy packets over time are supplied to the target, and the software needs to accumulate the dc-dc charge pulses over time before a new current value can be calculated. For currents under 1 µA, this can take up to one second, while for currents in the milliamp range, a current can be calculated every millisecond. Additional filtering is not applied so that detail information is not lost. Another factor that affects the energy (and with it, the current) that is consumed by the target is periodic background debug access during normal code execution, either through capturing of States information or through breakpoint polling. Try recording in Free Run mode to see a much smoother Power graph.
 
Q: I have a code that repeatedly calls functions that have the same size. I would expect the function profile to show an equal distribution of the run time. In reality, I see some functions having slightly more run time than expected, and some functions slightly less. 

A: During program counter trace, various factors affect the number of times a function is detected by the profiler over time. The microcontroller code could benefit from the internal cache, thus executing some functions faster than others. Another influencing factor is memory wait states and CPU pipeline stalls, which add time variance to the code execution. An outside factor is the sampling frequency of the debugger itself, which normally runs asynchronous to the microcontroller's code execution speed, but in some cases shows overlapping behavior, which also results in an unequal function run time distribution.
 
Q: My profile sometimes includes an <Undetermined> low-power mode, and there are gaps in the States graph Power Mode section. Where does the <Undetermined> low-power mode originate from? 

A: During transitions from active mode to low-power mode, internal device clocks are switched off, and occasionally the state information is not updated completely. This state is displayed as <Undetermined> in the Profile window, and the States graph shows a gap during the time that the <Undetermined> low-power mode persists. The <Undetermined> state is an indication that your application has entered a low-power mode, but which mode cannot be accurately determined. If your application is frequently entering low-power modes, the <Undetermined> state will probably be shown more often than if your application only rarely uses low-power modes.
 
Q: When capturing in EnergyTrace mode, the min and max values for power and current show deviation, even though my program is the same. I would expect absolutely the same values. 

A: The energy measurement method used on the hardware counts dc-dc charge pulses over time. Energy and power are calculated from the energy over time. Due to statistical sampling effects and charge and discharge effects of the output voltage buffer capacitors, it is possible that minimum and maximum values of currents vary by some percent, even though the program is identical. The captured energy, however, should be almost equal (in the given accuracy range).
 
Q: What are the influencing factors for the accuracy of the energy measurement? 

A: The energy measurement circuit is directly supplied from the USB bus voltage, and thus it is sensitive to USB bus voltage variations. During calibration, the energy equivalent of a single dc-dc charge pulse is defined, and this energy equivalent depends on the USB voltage level. To ensure a good repeatability and accuracy, power the debugger directly from an active USB port, and avoid using bus-powered hubs and long USB cables that can lead to voltage drops, especially when other consumers are connected to the USB hub. Furthermore the LDO and resistors used for reference voltage generation and those in the calibration circuit come with a certain tolerance and ppm rate over temperature, which also influences accuracy of the energy measurement.
 
Q: I am trying to capture in EnergyTrace+ mode or EnergyTrace mode with a MSP432 microcontroller that is externally powered, but there is no data shown in the Profile, Energy, Power and States window. 

A: Both EnergyTrace+ mode and EnergyTrace mode require the target to be supplied from the debugger. No data can be captured when the target microcontroller is externally powered.
 
Q: I cannot measure LPM currents when I am capturing in EnergyTrace+ mode. I am expecting a few microamps but measure more than 150 µA.
A: Reading digital data from the target microcontroller consumes energy in the JTAG domain of the microcontroller. Hence, an average current of approximately 150 µA is measured when connecting an ampere meter to the device power supply pins. If you want to eliminate energy consumption through debug communication, switch to EnergyTrace mode, and let the target microcontroller execute in Free Run mode.
 
Q: My LPM currents seem to be wrong. I am expecting a few microamps, but measure more, even in Free Run mode or when letting the device execute without debug control from an independent power supply.

A: The most likely cause of this extra current is improper GPIO termination, as floating pins can lead to extra current flow. Also check the JTAG pins again, especially when the debugger is still connected (but idle), as the debugger output signal levels in idle state might not match how the JTAG pins have been configured by the application code. This could also lead to extra current flow.

Q: When I start the EnergyTrace+ windows through View → Other → EnergyTrace before launching the debug session, data capture sometimes does not start. 


A: Enable EnergyTrace through Window → Preferences → Code Composer Studio → Advanced Tools → EnergyTrace™ Technology. When launching a debug session, the EnergyTrace+ windows automatically open, and data capture starts when the device executes. If you accidentally close all EnergyTrace+ windows during a debug session, you can reopen them through View → Other → EnergyTrace.

TI MSP43x Migration FAQ
 
Q: Can developers reuse their MSP430 MCU code on MSP432 MCUs?

A: MSP432 MCU users can continue using the development components (identified by red boxes in the graphic below) as they’ve done in MSP430 MCUs and also utilize new options (identified in blue). The new hardware and software components to take into consideration for porting are also shown in blue. Developers can read the MSP432 Platform Porting application note to learn how to port code between 16‐bit MSP430 MCU and 32‐bit MSP432 MCU platforms.
TI Cloud Development Tools FAQ
Go to: https://dev.ti.com/faq for frequently asked questions on TI Cloud Development Tools.
We will keep growing the FAQs as you come up with more questions, feel free to post them to this thread.
 
Happy coding!
On behalf of MSP432 MCU team 

**Attention** This is a public forum