1. MSP432™ MCUs Training Part 9: Porting between MSP430 and MSP432
Code Compatibility
Register Access & DriverLib
Interrupt
Intrinsics
Welcome to part 9 of the MSP432 MCU Training series. In this section we will take a closer look at a very specific topic that is to port code between the MSP430 and the MSP432. So you might be particularly interested in this section if you have an existing MSP430 or 432 project that you need to port to another platform. So in this section we will cover how code compatibility is covered between MSP430 and 432 at different levels. Register access, driver library code, how interrupts are being handled and how different MSP and intrinsics are being covered across the platform. Hopefully this section will give you an overview of how to port an existing application from one platform to another.

2. MSP Platform Portability
Hardware
Software
Development Tools
Development Kits
MSP 16-bit core
430
MSPWare
Register-Level
Driver
Library
Libraries
IAR IDE
Energia
CCS IDE
GCC
LaunchPad
BoosterPacks
Target Board
MSP430 Modules
MSP430
ULP Tools: ULP Advisor & EnergyTrace
Intrinsics & Interrupts
MSP Debugger
RTOSs
BSL
430
MSPWare
Register-Level
Driver
Library
CMSIS
ARM Modules
New MSP432 Modules
ARM M4F 32-bit core
432
ARM
Keil
ULP Tools: ULP Advisor & EnergyTrace+
Intrinsics & Interrupts
So first off the MSP platform provides high portability across the 16 and 32 bit families. At the high level, these are the different components of the hardware, software, tools and development kits ecosystem of the MSP430 and we have done quite a bit of work to make sure that these components of the ecosystem are also usable in the MSP432.
MSP432
Libraries
New for MSP432
Same as MSP430
Slight modifications from MSP430

3. Porting | Code Compatibility
Module
C-code
DriverLib
Recommendation
CORE SYSTEM
Core/CPU
New
msp430dna.h, intrinsic support available
Power
Develop new code using DriverLib APIs CS
Flash & RAM
NVIC
Develop new code using DriverLib,
CMSIS, or MSP432 intrinsics
ISR
Small changes
Special consideration for flag clearing & power modes when entering/exiting ISRs
Intrinsics
Some MSP430 intrinsics supported on MSP432
msp430dna.h converts applicable ones, helps guide through changing non-compatible ones to msp432/CMSIS intrinsics
MSP430
Digital: Timer_A, eUSCI, GPIO, AES
100% Portable
Port existing code, check & verify data types.
ADC14
Portable, new registers added
Portable, new APIs added
Port existing code, update code utilizing new features (14-bit, flag check, etc.), check & verify data types.
COMP_E, REF
AES, CRC
ARM
DMA
Use DriverLib APIs
Timer32
New, similar to TivaC
Simple modules: use C-code, DriverLib, or CMSIS
SysTick
Application Code
Take care of data types (16-bit, 32-bit, native int, signs, etc.) Try to use explicit C99 types (uint32_t) if possible.
Header file definitions, register names, bits compatible to MSP430
Existing register-access code compatible on MSP432
MSP430 DriverLib APIs  also compatible on MSP432
See interrupt/NVIC component below for specific interrupt changes.
Double-check if code has specific data-type (16-bit vs. 32-bit) requirements
New core system configuration code required.
No need to develop code from scratch: take advantage of DriverLib APIs and example to quickly configure and bring up system
Utilize new core features such as DC-DC, tunable DCO, dual flash banks, SRAM bank controls, etc.
CPU: check native data types, different code execution deterministic due to 3-stage pipeline
Register access code available, but DriverLib APIs recommended for complex module such as DMA
DriverLib APIs Similar to Tiva C DriverLib APIs
CMSIS register definitions compatible with other ARM devices.
Existing applicable MSP430 intrinsics usable on MSP432
Non-compatible MSP430 intrinsics are detected & guided to convert to MSP432 intrinsics
CMSIS core intrinsic functions also available.
As you can see many components are reusable across MSP432, the only thing that doesn’t really migrate will is the MSP 16-bit core. Obviously because that is replaced by a Cortex-M4 core. So let’s take a closer look at what is reusable, what’s fully compatible and what is extended for MSP432. So obviously, any of the existing MSP430 modules such as Timer A, ADC or eUSCI communication modules are 100% compatible across the platforms. New peripherals or peripherals inherited from ARM such as Timer32 or MicroDMA will be different from the MSP430 counterpart. This also gets translated over to the register level code as well as driver library code. So as you can see here existing MSP430 peripherals will be reusable, while the MSP432 and ARM peripherals will require new codes. Intrinsic and interrupts are also different from a device level. However with the help of software and compilers, we can actually bridge the gaps and make a little bit more similar between the MSP432 and MSP430. Moving on to the tools and development kits, as you can see, many of the existing tools and kits are reusable across different platforms thanks to the actual work we have put into ensuring the compatibility at the hardware level as well as the software level on MSP432. As an example, the ultra-low power tools such as ULP advisor and EnergyTrace have been extended from MSP430 to also work with MSP432. The highly compatible MSP ecosystem consisting of hardware, software, development tools and kits will allow developers to easily reuse their projects, code across the 16-bit and 32-bit platforms.

4. Porting | Direct Register Access
MSP430
MSP432
Let’s take a closer look at the code compatibility across the MSP430 and the MSP432. So we break it down into different components of the peripherals. Starting with Core system, these are the core modules that are necessary for any devices, such as the core, power, cpu clock system, memory and so on so forth. These are the ones that will always be new when you move from one family to another. These will require the most amount of work to port from any existing platform to the next . This is also usually the area where a lot of innovation is put into place to feature new technology to improve power consumption, performance or even new memory technology. So for these reasons, obviously, these new features will require new software solutions in order for the developers to fully leverage and take advantage of the new features. Most of the porting work will need to happen at this level.

5. Porting | DriverLib I2C Master Initialization
MSP430
MSP432
Moving on, intrinsics are the helper functions that are really specific to a CPU architecture, usually for a given platform such as MSP bit architecture, there are specific intrinsics that only work for MSP430. Similarly, MSP432 which is a Cortex M4 device, there are specific Cortex M intrinsics that usually only work across Cortex-M devices. However, with the help of our intelligent compilers as well as header files, we have been able to merge many of these changes to allow many existing intrinsics on MSP430 to also work on MSP432. This will allow existing MSP430 developers to copy and paste their code over to MSP432 and make minimal changes in order to get things to work.

6. Porting | CMSIS Support
CMSIS-style device header file
msp432_cmsis.h
CMSIS core header files
Supplied from ARM
Provide intrinsic/instruction support
CMSIS DSP & Math library
Moving on to the peripherals, there are two types of peripherals. First off are the MSP peripherals, these are the same ones that we on MSP430 toady such as Timer A, eUSCI and GPIO, ADC and so on so forth. Many of these peripherals are 100% identical across MSP430 and MSP432. For those you have 100% code compatibility, that means that you can just copy and paste the code over from one platform to another and it should work. One thing though to keep in mind, because of the 16-bit versus the 32-bit architecture, make sure that the data types are applicable to your specific platform. When in doubt, use explicit types such as C99 type. Some peripherals will be slightly updated such as ADC14 versus ADC12, for those, some minor modifications might be required. If your application code consist of mainly these peripherals, chances are you will need to spend very little time to port your code from one MSP to another.

7. Porting | MSP430 DNA & Intrinsic Support
Enabled using msp430dna.h & CMSIS standard library
Intrinsic functions:
__no_operation();
Low-power mode intrinsics
Stack pointer, registers, etc.
__delay_cycles();  Supported in CCS
Incompatible intrinsics are detected & recommended for MSP432 replacement
Detects all incompatibility
Guides developers through replacement & migration
Moving on, the second class of peripherals are the ARM peripherals such as DMA, Timer32 or Systec. Since these peripherals are new to MSP, we simple don’t have existing code today on MSP430 that can be reused on MSP432. However, the same code can be found on other TI ARM MCUs such as Tiva C.

8. Porting | Interrupts Declaration on MSP432
Option 1: Declare the entire Interrupt Vector table
Option 2: MSP430 method Use #pragma vector
#pragma vector = USCI_B0_VECTOR
__interrupt void USCI_B0_ISR(void) {
switch(__even_in_range(UCB0IV,12))
case 0: break; …… }
//All unused interrupts trapped
#pragma vector = unused_interrupts
__interrupt void intDefaultHandler(void)
//trap
msp432_startup_ccs.c
Last but not least the main application code is usually the higher level software that is not too dependent on the architecture itself. If developers utilize with proper software development techniques, and sufficient abstraction layers, the application code should not vary too much between MSP430 and MSP432 platforms. However, one thing to definitely keep in mind is the data type. In order to prevent any misuse of data types between 16bits and 32-bits, try to use explicit C99 types when possible.
ISR Handlers: stubs defined in table. Treated as regular function, code in user’s application
MSP430 code re-use
Interrupt vector & handler function defined together

9. Porting | Interrupts Usage on MSP432
Individual module interrupt sources
Module interrupt vector in NVIC
NVIC Master Interrupt
Ready INT
Alarm INT
Pre-scale T0
Pre-scale T1
Event INT
Reset
TimerA
Port6
. .
RTC
SysTick
Interrupt Event
Osc. Fault
Extra step for MSP432
RTC interrupt sources
Here’s a quick example of how direct register access code works across the different platforms. As you can see, this is a small piece of code that configures the Timer A module and turns on the interrupt. You can see that most lines of codes are identical across the MSP430 and the MSP432. The only difference here is how you enable interrupt and how you go to low power mode.
1. Enable module interrupt sources
2. Enable module interrupt in NVIC
3. Enable NVIC Master Interrupt
RTCPS1CTL |= RT1PSIE;
SCS_NVIC_ISER0 = INT_RTC_BIT;
__enable_interrupt();

10. Porting | Interrupts Usage on MSP432
Individual module interrupt sources
Module interrupt vector in NVIC
NVIC Master Interrupt
Ready INT
Alarm INT
Pre-scale T0
Pre-scale T1
Event INT
Reset
TimerA
Port6
. .
RTC
SysTick
Interrupt Event
Osc. Fault
Extra step for MSP432
RTC interrupt sources
Similarly when using driver library code on existing peripherals that are shared across the MSP430 and MSP432 the code looks 100% identical.
Next, many of the existing MSP430 intrinsics are now supported on the MSP432 platform with the use of the intelligent header file as well as the flexible compiler, especially inside the Code Composer Studio. Many of the existing intrinsics such as low operations and low power mode intrinsics as well as more advanced intrinsic functions such as delay cycles are now also supported inside Code Composer Studio. For the particular intrinsics that are really specific to 16-bit that are no longer usable on MSP432, the compiler actually detects all of these unusable intrinsics and flags it, and provide guidance for developers to go through the replacement process. For more information, open the MSP compatibility .h file that is part of the standard MSP432 header file for more information on these intrinsics.
Finally, let’s take a quick look at how interrupts can be handled across MSP430 and MSP432. If you recall, MSP432 is a Cortex-M4F device, and for that reason it uses the nesting vector interrupt controller or NVec, which is a big step up from the MSP430 interrupt module. NVEC allows you to have configurable priority interrupt as well as enhancements such as tail chaining to improve the latency between interrupt services. For a typical Cortex-M device project, usually the interrupt vector table is defined as a separate table in a separate file. As you can see on the left hand side, in here you will plug in the interrupt handlers that you need for your application. So by default this is the method that is supported for MSP432 across all of our compilers and IDEs such as CCS IAR or Kyle. On the other hand, the traditional MSP430 method is to use Pragma Vector, in this case you don’t need to define the entire interrupt vector table. In fact, you only need to specify the vectors that you actually use, using the pragma vector interrupt. You can also track the unused interrupts using the pragma vector. So the challenge here is “How do I copy my MSP430 code to MSP432, particularly for the interrupt service routine?”. The good news is that both methods are supported on MSP430, if you are starting out in a new Cortex-M project development, you can definitely use option number 1 on the left and define your interrupt vector table. However, if you have an existing MSP430 application and you want to reuse the interrupt service routines in MSP432, or if you want to develop with MSP432 application that you want to eventually port over to MSP430 platform in the future, you might want to use option number 2. These options are mutually exclusive, so if you have an interrupt vector table, make sure not to use the pragma vector or vice versa.
Another thing to note in terms of interrupt usage on MSP432 and this is particularly important for MSP430 users, is that on MSP430 the interrupt controller is part of the CPU so no actual handling is required. However, on MSP432, the NVec is an actual module that is between the individual peripherals and the mass interrupt. So on MSP432 you need to do two steps. One is to enable the interrupt triggers at the module level and then enable the master interrupt. However, on MSP432 there is one additional step that you need to do, and that is to map the individual module interrupt onto the NVec table, essentially enabling the module interrupt on the NVec level. This is the step number 2 as highlighted below. Vice-versa, if you need to port an existing 432 application back to MSP430, make sure to remove step number 2 because it is no longer relevant on MSP430.
So with that we have concluded the part 9 of the MSP432 MCU training series. Hopefully this section gave you an overview of what it takes to port an existing application from one MSP platform to another. Some of the things that you need to remember are whether you used register access code or driver library, how to handle interrupts, how to handle intrinsics and some of the you need to do when porting from 16-bit to 32-bit and vice versa. Thanks for watching!
1. Enable module interrupt sources
2. Enable module interrupt in NVIC
3. Enable NVIC Master Interrupt
RTC_enableInterrupt( RTC_CLOCK_READ_READY_INTERRUPT |
RTC_CLOCK_ALARM_INTERRUPT | RTC_PRESCALE_TIMER1_INTERRUPT);
Interrupt_enableInterrupt(
INT_RTC);
Interrupt_enableMaster();