Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.


From Texas Instruments Wiki
Jump to: navigation, search


Documentation and Training

I can not find information regarding the peripheral modules of a MSP430 device on the device datasheet, where can i find it?

There are basically three main documents for a MSP430 device:

  • The device datasheet: contains device specific information such as list of peripherals available on the device, memory organization, electrical characteristics, etc.
  • The Family User's Guide document: contains general information regarding internal modules (CPU, Peripheral, etc.) of a MSP430 device family (e.g. 1xx, 2xx, 4xx, 5xx/6xx).
  • The errata sheet: contains the list of bugs description and also the package markings. This is basically the main reference document containing the differences of different silicon revisions.

How to read the chip revision from the package marking?

The information for reading out the chip revision (along with other information such as Year and Month Date Code, LOT Trace Code, and Assembly Site Code) from the package marking can be found in the device specific Erratasheet.

Is there any thing like Device ID on MSP430 devices?

Refer to JTAG programming User's Guide tidoc:slau320, there is a table with the title "JTAG Features Across Device Families". This table contains the Device ID of all MSP430 devices. The Device ID on older 1xx/2xx/4xx devices is not specific for every device, instead it is specific for every sub-families (e.g. All MSP430F13x, MSP430F14x, and MSP430F14x1 have the same device ID 0xF1 and 0x49).

In the MSP430F5xx/6xx/FRxx devices, there is a possibility to create a unique Device ID by using the "Die Record" field of the "DEvice Descriptor Table" which can be found usually at the end of the device specific datasheet. The following shows the Device Descriptor Table MSP430:

Msp430fr59xx die record.png

Where can i find the list of MSP430 application notes?

Please refer to this link.

Is there any MSP430 online training?

Yes, please refer here.

Which algorithm is used for calculating the TLV checksum on 5xx/6x devices?

The algorithm used is CRC_CCITT with following parameters:

  • Initial value (seed): 0xFFFF
  • Polynom: 0x1021
  • Indirect: False
  • Reverse data: False
  • Reverse CRC before final XOR: False
  • Final XOR value: 0x0

The address range for the CRC is 0x1A04 – 0x1AFF.

Is the calibration data available on MSP430F471xx INFOA memory?

No. The datasheet does not explicitly state this, but the calibration data is not delivered inside INFOA of MSP430F471xx after production.

Is there any information regarding the reliability of MSP430 devices?

Refer to the TI Reliability Estimator.

How to assign USB VID (Vendor ID) and PID (Product ID) number on MSP430 devices with USB interface?

The VID and PID number of MSP430 devices with USB interface is basically not "hard-wired" in the hardware, instead it is basically part of the free-open source code USB stack software. Please refer to the MSP430USBDEVPACK to download the USB software stack and the USB Descriptor Tool which is used to generate header files containing configurations (including VID and PID number) needed to compile the USB stack.

TI offers the customer a possibility to use TI USB VID (Vendor ID) in their product with a unique PID number. Send the request for the "VID Sharing Program" at the following link:

How to get information regarding MSP430 new device roadmap?

The information regarding new device roadmap is not publicly released. Please contact either TI local sales office or TI authorized distributor for getting this information.

Migrating Guide

Below is the list of migrating guide between MSP430 family devices

To From Link Note
MSP430FR58xx, MSP430FR59xx MSP430F2xx, MSP430G2xx tidoc:slaa559
MSP430FR58xx, MSP430FR59xx MSP430F5xx, MSP430F6xx tidoc:slaa555
MSP430FR57xx MSP430F2xx tidoc:slaa499
MSP430F5xx MSP430F2xx, MSP430F4xx tidoc:slaa396
MSP430F541xA/F543xA MSP430F541x/F543x tidoc:slaa419
MSP430F21x2 MSP430F12x(2) tidoc:slaa421
MSP430F13x/14x MSP430F23x/24x tidoc:slaa381
MSP430F16x MSP430F261x tidoc:slaa380
MSP430F42x MSP430F42xA Device is hardware (pin-to-pin) and software compatible (can be seen by comparing header file for CCS/IAR; might only need device type change in the IDE project and recompilation). Difference only on hardware parameter (refer to the device datasheet tidoc:slas241)
MSP430F11x1 MSP430F11x1A Device is hardware (pin-to-pin) and software compatible (can be seen by comparing header file for CCS/IAR; might only need device type change in the IDE project and recompilation). Difference only on hardware parameter (refer to the device datasheet & erratasheet tidoc:slas587, tidoc:421)
IAR assembly code CCS assembly code Refer to the MSP430 CCSTUDIO compiler User's Guide tidoc:slau157 - Appendix C: Migration of Assembler Code from IAR 2.x, 3.x, or 4.x to CCS

Tools and Programming

I am a beginner in MSP430, how can i develop my application in a more efficent and faster way?

If you are programming in C (which is very common nowadays), the most difficult thing to start with a new microcontroller hardware platform is to get know the peripherals. The CPU itself is not a problem, since the code is written in C. Therefore explore the possibilities which TI offers to make it easier for you working with MSP430 peripherals here: MSP430 Software, which includes:

  • Example codes: TI provides tons of example codes for every MSP430 devices
  • GRACE: a graphical user interface to setup/initialize the MSP430 peripherals
  • MSP430ware: extensive collection of all example codes, driver libraries (for 5xx,6xx, and FRAM devices), User's Guide for all MSP430 devices.

Does TI provide development kit/board for my MSP430?

TI provides development kit for all MSP430 devices, but not in all packages. The development kit can be found usually at the "Softare and Development Tools" section on the device product web page shown as follows:

Msp430 software tools tab.PNG Msp430 software tools tab 1.PNG

Which MSP430 target device does my FET (Flash Emulation Tool) support?

This information can be found in the MSP430 Debuggers User's Guide(tidoc:slau647) Chapter 2. "MSP Debug Probe Overview" as follows:

Msp430 fet tools.PNG

This list above basically shows the correlation between FET tools and the target devices which are guaranteed and supported by TI. This means that basically it is possible to use a FET tool to program another device(s) not listed in the list above, but in this case TI will not provide support or bug fix in case it doesn't work.

How can i generate TI TXT output file with CCSTUDIO or IAR?

Refer to the following wiki: Generating_and_Loading_MSP430_Binary_Files

Which software can be used to download/flash a binary (e.g. TI TXT) file to my MSP430 target device?

Use either the MSP430 Flasher or the Elprotronic FET Pro-430 Lite Software to download/flash/program the MSP430 target device. Both software are free.

Which version of the MSP430.DLL is used in my IDE (IAR/CCS)?

Using Windows Explorer, go to the default folder containing the DLL files:

  • CCSv5: C:\ti\ccsv5\ccs_base\DebugServer\drivers
  • CCSv4: C:\Program Files\Texas Instruments\ccsv4\DebugServer\drivers
  • CCE: C:\Program Files\Texas Instruments\CC Essentials v3\DebugServer\drivers
  • IAR: C:\Program Files\IAR Systems\Embedded Workbench 5.0\430\bin

and click on the DLL files. The information should be shown at the bottom of the Windows Explorer as follows:

Msp430 v3 dll version.PNG

How does the recommended JTAG pinout for MSP430 devices look like?

Please refer the following wiki page.

Where can i find the list of MSP430 devices with the JTAG type (4-wire or 2-wire)?

The information can be found MSP430 Programming via JTAG User's Guide: tidoc:slau320, Table 1-14 "JTAG Features Across Device Families".

Does TI provide MSP430 tools programmer for mass production?

Yes, please see MSP-GANG.

How is the compliance between MSP430 JTAG with IEEE 1149.1?

The MSP430 JTAG interface implements the test access port state machine (TAP controller) as specified by IEEE Std 1149.1. However there are some restrictions on MSP430 JTAG (non-compliance with IEEE Std 1149.1):

  • The MSP430 device must be the first device in the JTAG chain (because of clocking via TDI and JTAG fuse check sequence).
  • None of the MSP430 devices has Boundary Scan Cells
  • Only the BYPASS instruction is supported. There is no support for SAMPLE, PRELOAD, or EXTEST instructions.
  • The JTAG pins are shared with port functions on certain devices; JTAG function controlled via TEST pin.

Where can I find the BSDL (Boundary Scan Description Language) for MSP devices?

The MSP430 JTAG does not support boundary scan since it is not 100% compliance with the IEEE 1149.1. See #How is the compliance between MSP430 JTAG with IEEE 1149.1?.

Which checksum algorithm is used by the MSP-GANG430 to verify the memory content?

The MSP-GANG430 uses the PSA (Pseudo Signature Analysis) which looks like this:

for (PSA = StartAddr - 2, i = 0; i < Length; i++)
  if (PSA & 0x8000)
    PSA = ((PSA ^ 0x0805) << 1) | 1;
    PSA <<= 1;
  PSA ^= Data[i];

How can i compile the BSL Scripter and BSLDEMO2 source codes from SLAU319?

Starting at version E of the SLAU319 (tidoc:SLAU319), the source codes are delivered together with the Microsoft Visual Studio project files.

The MSP430F54xx (non-A) devices has SYS4 bug, but i still can erase and reprogram the BSL. How is it possible?

Erasing or over-writing the BSL of MSP430F54xx (non-A) devices are both are technically possible, but neither is recommended since there are a number of errata that make code execution out of non-MAIN memory flash unreliable for the F5438. Very detailed workarounds were used for the F5438 BSL implementation. Most of the time it is unlikely to be successfully executing code out of non-MAIN flash in the F5438.

How to find out the memory size of the MSP430 application in CCSTUDIO?

Per default, when the CCSTUDIO has successfully compiled the code, it will generate a MAP file (per default under "Debug" folder with the name <PROJECT_NAME>.map). In the MAP file, there is a list of memory sections together with the information regarding used and unused memory size. The memory sections are basically derived from the linker command file (lnk_msp430xxxxx.cmd). The calculate memory size doesn't consider the dynamic allocation memory from the heap memory e.g. by using malloc() function.

The following example is taken from the MAP file of simple Blink LED for MSP430G2553:

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  SFR                   00000000   00000010  00000000  00000010  RWIX
  PERIPHERALS_8BIT      00000010   000000f0  00000000  000000f0  RWIX
  PERIPHERALS_16BIT     00000100   00000100  00000000  00000100  RWIX
  RAM                   00000200   00000200  00000050  000001b0  RWIX
  INFOD                 00001000   00000040  00000000  00000040  RWIX
  INFOC                 00001040   00000040  00000000  00000040  RWIX
  INFOB                 00001080   00000040  00000000  00000040  RWIX
  INFOA                 000010c0   00000040  00000000  00000040  RWIX
  FLASH                 0000c000   00003fe0  000000b2  00003f2e  RWIX
  INT00                 0000ffe0   00000002  00000000  00000002  RWIX
  INT01                 0000ffe2   00000002  00000000  00000002  RWIX
  INT02                 0000ffe4   00000002  00000000  00000002  RWIX
  INT03                 0000ffe6   00000002  00000000  00000002  RWIX
  INT04                 0000ffe8   00000002  00000000  00000002  RWIX
  INT05                 0000ffea   00000002  00000000  00000002  RWIX
  INT06                 0000ffec   00000002  00000000  00000002  RWIX
  INT07                 0000ffee   00000002  00000000  00000002  RWIX
  INT08                 0000fff0   00000002  00000000  00000002  RWIX
  INT09                 0000fff2   00000002  00000000  00000002  RWIX
  INT10                 0000fff4   00000002  00000000  00000002  RWIX
  INT11                 0000fff6   00000002  00000000  00000002  RWIX
  INT12                 0000fff8   00000002  00000000  00000002  RWIX
  INT13                 0000fffa   00000002  00000000  00000002  RWIX
  INT14                 0000fffc   00000002  00000000  00000002  RWIX
  RESET                 0000fffe   00000002  00000002  00000000  RWIX

Starting from CCS v5.x, there is graphical representation of the memory allocation based on the MAP file content. The graphical tool can be accessed under: "View" -> "Other..." -> "Code Composer Studio" -> "Memory Allocation".

How to invoke the BSL?

There are basically two types of BSL: UART BSL and USB BSL.

  • The UART BSL can be invoked by applying a special BSL entry sequence during reset shown as follows:
Msp430 bsl entry sequence.PNG

(Devices with shared JTAG pins have TEST pin, and devices with dedicated JTAG pins don't have TEST pin)

  • The USB BSL can be invoked by either of the following conditions are met when the device is powered by VBUS:
    • The device is powered up by USB and the reset vector is blank.
    • The device powers up with the PUR pin tied to VUSB.

Which RS232 pin does the BSL Scripter use for connecting RST and TEST/TCK signals?

The BSL Scripter and BSLDEMO use DTR pin to control RST signal and RTS pin to control TEST/TCK signal on MSP430 target device.

How to find out which compiler version I am using in CCSTUDIO?

Go to "Project" -> "Properties", and select the "General" option, you can find the information under "Compiler Version":

Ccs v5 set compiler version.PNG

How to enable the access to BSL Flash memory in MSP430F5xx/6xx devices ?

Per default the access to the BSL Flash memory in MSP430F5xx/6xx devices is protected by the SYSBSLPE bit of the SYSBSLC register. Therefore in order to be able the gain the access, the protection needs to be turned off. Normally the debugger/programmer will have an extra option for this:

NOTE: Some of the released 5xx/6xx BSL's source codes and binary files can be found in the associated/collateral files of SLAA450 Application Note.

Debugger/Programmer BSL Access Option
CCS (Code Composer Studio) Jtag bsl access ccs v5.PNG
IAR EWB Jtag bsl access iar.PNG
Elprotronic FET-Pro430 Jtag bsl access elprotronic fet pro430.PNG
MSP-GANG Jtag bsl access ccs msp gang.PNG
MSP430 Flasher -b parameter

How to protect the calibration data in INFOA memory on MSP430x2xx devices during programming ?

Per default the access to the INFOA memory in MSP430F2xx/6xx devices containing the calibration data is protected by the LOCKA bit of the FCTL3 register. As long as the LOCKA bit keep set, any mass erase command will not erase the InfoA memory. Normally the debugger/programmer will have an extra option for enabling erasing the InfoA memory:

Debugger/Programmer BSL Access Option
CCS (Code Composer Studio) Msp430 infoa protect ccs v5.PNG
IAR EWB Msp430 infoa protect iar.PNG
Elprotronic FET-Pro430 Msp430 infoa protect elprotronic fet pro430.PNG
MSP-GANG Msp430 infoa protect msp gang.PNG
MSP430 Flasher -u parameter

How to suppress a warning message in CCS?

The warning messages in CCSTUDIO can be suppressed by using the --diag_suppress compiler option like the following:

Ccs v5 suppress warning 10374.PNG

This will make the warning message to be suppressed globally in the entire source codes of CCS project. If the warning message(s) shall only be suppressed locally in a certain part of code, the pragma diag_suppress' and diag_default can be used:

#pragma diag_suppress=WARNING_NUM
// all warning messages with WARNING_NUM in this section will be suppressed
#pragma diag_default=WARNING_NUM

The following shows an example:

Ccs v5 suppress warning local.PNG

As can be seen above, the compiler should basically return warning messages for test_func1 and test_func2 since both functions should basically deliver a return value according to the function type declaration. However since test_func1 is within the scope of pragma diag_suppress and diag_default which disable/suppress the warning message, the compiler only gives warning for test_func2.

Calculating MSP430 BSL Checksum

The following javascript can be used to calculate the MSP430 BSL checksum values:


DISCLAIMER: the script shall be used "as is" without any support or warranty

Is it possible to debug a running MSP430 device?

Please refer to the following wiki: MSP430_-_Connecting_to_a_running_target

Where can i find the list of intrinsic functions and parameters of CCSTUDIO an IAR?

The intrisic functions are declared in a header file called "in430.h" while the parameters (e.g. LPM0_bits for __bis_SR_register()) are defined in the device specific header files (e.g. "msp430f5r5969.h" for MSP430FR5969). The header files which can be found usually in the following directory:

  • CCS v5: <CCS_BASE_DIRECTORY>\ccsv5\ccs_base\msp430\include
  • IAR: C:\Program Files\IAR Systems\Embedded Workbench x.y_z\430\inc

Tips and Tricks

Is there anyway to get interrupt at pins on ports which are not P1 and P2?

Per default, only P1 and P2 can take GPIO input interrupt. However there are tricks which might simulate interrupt on other port pins: MSP430_-_Alternate_GPIO_Interrupt.

How to assign the correct Timer_A interrupt vector?

Each Timer_A has basically two interrupt vectors:

  • one for CCR0
  • another one for TAIFG and the rest of CCRx.

The format for interrupt vector in CCS and IAR header file is TIMER(X)_A(Y)_VECTOR where:

  • X is the module number (e.g. for MSP430G2553 with two Timer_A module TA0 and TA1: 0=TA0, 1=TA1)
  • Y is the vector number (0=CCR0, 1=TAIFG&other CCRs)

Is it possible to generate software reset?

The easiest way to generate software reset is by using the watchdog timer like the following:

#define SW_RESET()      WDTCTL = WDT_MRST_0_064; while(1);  // watchdog reset

On 5xx/6xx and CC430 devices which have PMM (Power Management Module), there is a possibility to generate software BOR and software POR as follows:

#define SW_RESET()      PMMCTL0 = PMMPW + PMMSWBOR + (PMMCTL0 & 0x0003);  // software BOR reset
#define SW_RESET()      PMMCTL0 = PMMPW + PMMSWPOR + (PMMCTL0 & 0x0003);  // software POR reset

Is it possible to retrieve the cause of a reset?

On 5xx/6xx devices, there is a possibility to check the cause of last reset by checking the SYSRSTIV register.


To be able to debug this properly, it is necessary to save the SYSRSTIV register value during startup by using the low level C initialization function such as follows:

For CCS compiler:

// global variable for storing the reset cause
#pragma NOINIT (SysRstIv);
unsigned int SysRstIv;
int _system_pre_init(void)
  // stop WDT
  // save reset information
  SysRstIv = SYSRSTIV;
  // Perform C/C++ global data initialization
  return 1;

For IAR compiler:

// global variable for storing the reset cause
__no_init unsigned int SysRstIv;
int __low_level_init(void)
  // stop WDT
  // save reset information
  SysRstIv = SYSRSTIV;
  // Perform data segment initialization
  return 1;

How can I disable the access the Flash memory access to protect my IP?

There basically three ways for accessing Flash memory:

  • via JTAG access
  • via BSL (Bootstrap Loader)
  • via custom access implemented in the application (optional)

In order to disable flash access via JTAG, the JTAG fuse shall be blown. On the older 1xx, 2xx, 4xx devices, the JTAG fuse is implemented as a physical fuse, while on the newer 5xx/6xx device it is implementead as an electronic fuse.

BSL can be disabled on 5xx/6xx devices by erasing the BSL memory flash, or on some older 2xx devices by disable the JTAG via a setting of special register usually found under the interrupt vector table.

The debugger/programmer tool unexpectedly reports that JTAG fuse is blown, can i do something about it?

Unlike the older 1xx, 2xx, 4xx devices which use physical JTAG fuse, the 5xx/6xx/FRAM devices have basically electronic JTAG fuse (e.g. refer to the 5xx/6xx User's Guide document - chapter 1.11.2 "JTAG Lock Mechanism via the Electronic Fuse"). As long as the BSL is not disabled/erased, it is possible to check the status of the JTAG fuse via BSL. For more information regarding the MSP, refer to the MSP430 BSL wiki page: BSL_(MSP430).

TODO: provide example BSL scripts to do this

Is there a way to re-allocate the interrupt vector on MSP430?

On the 5xx/6xx family devices, it is possible to re-allocate the interrupt vectors to the RAM by setting the SYSRIVECT of the SYSCTL register. By relocating the interrupt vector to RAM, the BSL code is able to use interrupt in which the interrupt vector of the BSL will not collide with the ones for the applications.

The following example code shows how to do this on MSP430F5438A:

  • CCS v5.x (compile option: --code_model==small):


  • IAR:


How to generate random number with MSP430 devices?

Most of MSP430 devices are delivered with on-chip low power VLO clock which is usually specified with a big range of clock frequency in the datasheet (usually from 6 kHz minimum value to 14 kHz maximum value).

There is an application note which describes on how to generate random number based on the VLO for the 2xx devices. The basic idea of the application note is to use the VLO to source ACLK, and the ACLK is used also as input as a Timer_A capture event for capturing a free running Timer. Therefore it is necessary to first of all check the device specific datasheet to allocate the correct CCR (Capture Compare Register) which is able to use ACLK as its input event (the input signal is internally connected to ACLK). The following Timer_A signal connection table is cited from the the MSP430F51xx device datasheet:

Timer A F51xx signal connections.PNG

As can be seen above, for the MSP430F51xx devices, the CCR1 register is to be used for generating the random number. The application note also describes some techniques to add the randomness inside the code. Below is the example code for generating random number of MSP430F51xx devices:

int TI_getRandomIntegerFromVLO(void)
  unsigned int i;
  int result = 0;
  // setup Timer_A
  TA0CCTL1 = CM_1 + CCIS_1 + CAP;
  for(i=0 ; i<16 ; i++)
    // shift left result
    result <<= 1;
    // wait until Capture flag is set
    while(!(TA0CCTL1 & CCIFG));
    // clear flag
    TA0CCTL1 &= ~CCIFG;
    // check LSB
    if(TA0CCR1 & 0x01)
      result |= 0x01;
    // change the divison of timer input clock
    TA0CTL = (TA0CTL & 0xFCFF) | ((TA0CCR1 & 0x03) << 8);
  return result;

CCS Compiler Warning #10374-D

In the new CCS compiler(Code Generation Tools/CGT) of CCS v5.x, the compiler will give such warning:

  1. 10374-D Interrupt vector "USI" does not have an interrupt handler routine.

if it founds any interrupt vector is uninitialized. The reason behind this is basically it is good practice to initialize all interrupt vectors, so that in case of spurious interrupt which occurs unexpectedly, the MSP430 will not get reset due to the uninitialized interrupt vector.

The following example shows an example how to create a "TrapIsr" to remove the warning given by the CCS compiler on this issue:

#include <msp430g2231.h>
int main(void)
  WDTCTL = WDTPW + WDTHOLD;		// Stop watchdog timer
  P1DIR |= BIT0;					// Set P1.0 to output direction
    P1OUT ^= BIT0;				// Toggle P1.0 using exclusive-OR
// trap isr assignation - put all unused ISR vector here
__interrupt void TrapIsr(void)
  // this is a trap ISR - check for the interrupt cause here by
  // checking the interrupt flags, if necessary also clear the interrupt
  // flag

See also #How to suppress a warning message in CCS?.

How to put a variable in a specific memory location?

Refer to the following wiki: Placing_Variables_in_Specific_Memory_Location_-_MSP430

How to put generate the MSP430x5xx/6xx JTAG lock in the code?

Refer to the following wiki: Placing_Variables_in_Specific_Memory_Location_-_MSP430#Generating_JTAG_Lock

How does the 4 pin SPI work on USCI module?

On USCI module, UCxSTE is used as activation input pin in 4 pin SPI mode (UCMODEx = 01 or 10) for the USCI module both in master and slave mode, as shown in the following table:


4 pin USCI SPI Master Mode

In 4-pin master mode, UCxSTE is used to prevent conflicts with another master. When UCxSTE is in the master-inactive mode:

  • UCxSIMO and UCxCLK are set to inputs and no longer drive the bus.
  • The error bit UCFE is set, indicating a communication integrity violation to be handled by the user.
  • The internal state machines are reset and the shift operation is aborted.

4 pin USCI SPI Slave Mode

In 4-pin slave mode, UCxSTE is used by the slave to enable the transmit and receive operations and is provided by the SPI master. When UCxSTE is in the slave- inactive state:

  • Any receive operation in progress on UCxSIMO is halted.
  • UCxSOMI is set to the input direction.
  • The shift operation is halted until the UCxSTE line transitions into the slave transmit active state.

How to generate interrupt on transmission completion using the USCI module?

In USCI module, the transmit interrupt is generated when the UCxTXBUF data byte is copied/shifted to the TX shift register. However it is sometime necessary to detect/generate interrupt if the whole data byte has been shifted out by from the TX shift register. to There are several possible way to do this:

  • run a timer when the transmit interrupt occur to generate timer interrupt based on the calculated time for transmitting the whole byte.
  • set UCLISTEN bit of UCSxSTAT register in order to loopback the transmitted data byte into the receiver. By activating the receive interrupt, it is possible to emulate the interrupt using the receive interrupt. More detailed information can be found in the following E2E discussion

Is there any list of recommended crystal oscillators for MSP430 devices?

TI doesn't provide a list of recommended crystal oscillators for MSP430 devices. Usually it is recommended for users to use the set the load capacitors of the crystal oscillator according to the specified value of the crystal manufacturers by using either internal XCAP values or external load capacitors. We also recommend customers to test thoroughly the crystal as described in the application note tidoc:slaa322 chapter 4.

Code Reference

Checklist for designing custom board with MSP430

  • Make sure that the pin-out connections comply to the development kit offered by TI. TI offers development kits for almost every MSP430 devices (but not every package type). The schematic of the MSP430 devices can be found in tidoc:slau278.
  • Make sure that JTAG pinout complies to the recommended one: JTAG_(MSP430).
  • Other recommended reference for hardware design guide with MSP430 microcontrollers:
  • Consider the power supply vs CPU frequency consideration as described here.

Running Code from SRAM

To lower power consumption, sometime it is useful to execute codex from SRAM. There are some examples for this: the flash write example for MSP430F543x or refer to this small guide.

Setting USCI Module UART Mode Baud Rate

Calculate using the USCI_UART_Baud_Rate_Gen_Mode_Selection#USCI_UART_Calculator USCI UART baud rate calculator or use the usci_settings.h from this link.

Using MSP430F5xx/6xx BSL Flash Memory Area for Application Data/Code

On MSP430F5xx/6xx device, it is possible to use the BSL Flash memory area if the BSL is not intended to be used by the application. For this purpose, refer to the following guide.

FFT Code for MSP430

Please refer to the MSP-EXP430F5438 User's Experience software code: tidoc:slac227

How to compile MSP430F5xx/6xx USB BSL

As described in the BSL User's Guide tidoc:slau319 - chapter 3.5 "BSL Command Structure", the default USB BSL in the MSP430F5xx/6xx devices is implemented only to support a subset of commands (RX DATA BLOCK_FAST, RX PASSWORD, and LOAD PC) which is used to load the full BSL into the device RAM supporting more commands which is used to load the firmware to the on-chip device flash memory. This means that basically the MSP430F5xx/6xx BSL is implemented as a two-stage bootloader - the "Flash BSL" (first stage bootloader, used to load full-support BSL into the device RAM) and the "RAM BSL" (second stage bootloader, used to load device firmware to device flash memory).

Both "Flash BSL" and the "RAM BSL" uses the same source code as described in the MSPBSL CUSTOM-BSL430 software package, and the difference with the following difference:

  • Linker Configuration File: "Flash BSL" uses lnk430_BSL_AREA_RAM_2400-33FF.xcl, while "RAM BSL" uses lnk430F5529_RAM_AREA.xcl - both are available under MSP430BSL_1_xx_yy_zz\5xx_6xx_BSL_Source\MSP430F552x_USB\CONFIG folder
  • Preprocessor macros: in "BSL_Device_File.h", "Flash BSL" uses the following macros:
//Device Specific Definitions for commands and bugs
#define RAM_WRITE_ONLY_BSL 0x80
//#define FULL_FLASH_BSL
//#define RAM_BASED_BSL      1

while "RAM BSL" uses the following macros:

//Device Specific Definitions for commands and bugs
//#define RAM_WRITE_ONLY_BSL 0x80
#define RAM_BASED_BSL      1
  • The BSL430_Low_level_init.s43 shall be removed from compilation when trying to compile the "RAM BSL"

NOTE: when trying to debug the "RAM BSL" during development, it is necessary to also add the USB enumeration process. This is not needed for the "release version" of the "RAM BSL" since the SUB has been enumerated by the first stage "Flash BSL". To add the enumeration process change the PI_Init() function in BSL430_USB_PI.c from:

void PI_init()
  USBKEYPID = 0x9628;
  USBCNF = 0;
    //init USB
    wUSBPLL = *(&cSPEED_4_PLL);


void PI_init()
#if defined (RAM_BASED_BSL) && !defined (RAM_BSL_DEBUG)
  USBKEYPID = 0x9628;
  USBCNF = 0;
    //init USB
    wUSBPLL = *(&cSPEED_4_PLL);

and add the defintion/compiler option RAM_BSL_DEBUG to the project setting.

Technical FAQ

How to set a I/O pin as peripheral pin?

In each device specific datasheet, there is a special chapter (usually found at the end of the documents after the electrical characteristic parameters called either "APPLICATION INFORMATION" or "Input/Output Schematics") describing the I/O pins schematics and also the register settings to set a pin either as normal GPIO pin or as peripheral pin.

Maximum GPIO current source/sink

The MSP430 datasheet usually does not specify the maximum current a GPIO pin can source/sink. However there are two limitations which shall be considered:

(1) Because the MSP430 has CMOS GPIO, the high-level output voltage VOH will decrease when the pin source sources current while the low-level output voltage VOL will increase if it sinks current. The following values are taken e.g. from the MSP430F22x2 and MSP430F22x4 datasheet:

Msp430f22xx output specs.PNG

As can be seen above, if for example an output tries to source 1.5 mA at Vcc=2.2V or 3V, it shall be expected that the VOH drop to a minimum value of Vcc-0.25 V. When sourcing 6 mA at the same Vcc level, the output can even drop to a minimum of Vcc-0.6 V. When the output port tries to sink current, it shall expect an increase of low-level output voltage VOL specified above, e.g. maximum Vss+0.25 V when sinking 1.5 mA at 2.2V or 3V. Another thing to be noticed is also as described in the footnotes, the specified VOL and VOH values above are only valid if the maximum total source/sink current doesn't exceed the specified value in the footnote.

(2) When trying to sink a large amount of current, the main impact of increased power dissipation is the increase in junction temperature. For example by using the ROT formula for calculating: Temp (junction) = theta (j-a) * P + Temp(ambient). For example if the output pin does 5mA current sink at 50 degC:

Power dissipated P = voltage drop * I = 3V * 35mA = 105mW

For the MSP430F1232 (28 DW package) from the packaging website, it specifies Theta (j-a) = ~50 C/W. Using a max. power dissipation of 200mW (from CPU + modules + GPIO) we get;

Temp (junction) = 50 * 0.2 W + 50C = ~60C.

This is still within the abs. max. rating for the device i.e. 85C. Note that these calculations are only general guidelines for understanding the impact of sinking excessive current. The user is expected to check and protect against short circuits on the application hardware.

What is the state of GPIO when the device is in reset state?

While the device is being held in reset the GPIO pins are at their default state i.e. input/high impedance and floating The pull-ups are also not enabled in this state.

Maximum CPU frequency

The maximum CPU frequency is defined in the device specific datasheet usually under the "Recommended Operating Conditions", but in general for it is 8 MHz for the 1xx devices, 16 MHz for the 2xx devices, 8/16 MHz for 5xx devices, and 25 MHz for 5xx/6xx devices.

Another most asked question to this topic is that why the datasheet specifies DCO/external clock (XT1/XT2) frequency which is higher than the maximum CPU. This is true that the clock system might accept higher external clock signals from XT1/XT2 (e.g. for MSP430F5438A, max XT1/XT2 is specified as 32 MHz) and even operate DCO frequency to higher frequency (e.g. for MSP430F5438A up to 135 MHz), but the clock frequency shall be scaled down using the DIVA, DIVM, or DIVS pre-scaler before sourcing out the ACLK, MCLK, or SMCLK clock signals.

Why should it be possible to run 5xx/6xx UCS DCO clock to frequency higher than 25 MHz?

The short answer for this is basically to reduce the jitter caused by the DCO modulation done by the FLL. The FLL of UCS module stabilizes the DCO output by switching between two frequencies: fDCO and fDCO+1. This causes a jitter for example on MSP430F5438A between 2-12% (see the following specification taken from the datasheet).

MSP430F5438A DCO Freq Spec DCO Step.PNG

By allowing the DCO to produce higher frequency which will be then later on divided down to desired output frequency soucing ACLK/MCLK/SMCLK, the jitter affect could be minimized. For example when trying to run the device at 8 MHz which has maximum hitter of 12%, setting the DCO as clock source with 64 MHz and divider of /8, will cause the output clock to have maximum of 1,5% (12%/8).

My MSP430 seems doesn't run during startup, what could be the problem?

There are several common problems which prevent a MSP430 device having a problem during startup (device seems not to work at all):

Running CPU at higher frequency without adequate power supply

If you are running the CPU in higher frequency, the most common problem is that the CPU is set to run at the higher frequency before the minimum supply voltage is reached. This problem occurs if Vcc is ramping relatively slowly than the default code which sets the CPU frequency. This information can be found in the device datasheet usually at the section "Recommended Operating Conditions". For example the following figure shows the diagram of CPU/System Freq (MCLK) vs Supply Voltage Vcc for MSP430F44x.

F449 freq vs vcc.PNG

In this case, the workaround would be to create a small delay at start-up before setting up the CPU to run at higher frequency, or to measure the Vcc using internal ADC to make sure that the appropriate Vcc level has been reached before running the CPU at higher frequency.

On 5xx/6xx devices, it is not the supply voltage that matters to run CPU on higher frequency. Instead the VCORE level of the PMM (Power Management Module). To set the VCORE level, it is advised to use the driverlib of MSP430Ware. The following figure shows the diagram of CPU/System Freq (MCLK) vs VCORE level for MSP430F543xA.

F5438a vcore vs vcc.PNG

Another problem might arise if the CPU is running at higher frequency and the supply voltage drops during run-time. In this case, it is advised to keep the device in reset state as long as the supply voltage drops below the adequate minimum voltage needed for running the CPU at the higher frequency. Failing to do so, the device can't be no longer guaranteed to work properly, and even it could cause severe damage such as flash memory corruption (refer to: MSP430_Flash_Best_Practices).

On 1xx, 2xx, 4xx devices, some device have SVS (Supply Voltage Supervisor) on-chip module which can be used for this purpose. For the device which doesn't have the SVS module, it is advised to use an external supply voltage supervisor. On all 5xx/6xx and FRAM devices, the PMM (Power Management Module) can also be used to generate reset if the supply voltage drops under certain threshold.

WDT fires during C startup code

Another most common problem if the application is written in C language is the watchdog timeout during startup. Per default watchdog timer on all MSP430 is set to active after startup. Therefore it is necessary to turn off the WDT if not needed right at the beggining of the application code. If the application code is using large variables which are needed to be initialized during startup, this could cause that the watchdog timer already fires during startup and the code will never be run.

For CCS MSP430 compiler 4.2.0 and later the solution is to set the linker --cinit_hold_wdt option to on to hold the watchdog during C auto-initialization:

Cinit hold wdt.PNG

Setting the linker --cinit_hold_wdt to on means the watchdog is only held inactive during C auto-initialization, and so the watchdog will be active upon entry to main.

For other compilers the solution for this problem is to use the compiler's low level C initialization function which is called even prior to the initialization of C variables. In CCS compiler, it is called "int _system_pre_init(void)", while in IAR, the function is called int __low_level_init(void). The return value is used to determine whether or not C/C++ global data initialization will be performed (return value of 0 to bypass C/C++ auto-initialization). Refer to the MSP430 Software Coding Techniques Appication Report, chapter 3.6 "Using a Low-Level Initialization Function" for more detailed information regarding this issue. Holding the watchdog inactive in the low level C initialization function means the watchdog will be held inactive upon entry to main.

For CCS compiler:

int _system_pre_init(void)
  // stop WDT
  // Perform C/C++ global data initialization
  return 1;

For IAR compiler:

int __low_level_init(void)
  // stop WDT
  // Perform data segment initialization
  return 1;

Incorrect assignment of interrupt vector

There are some cases in which the interrupt vector is not assigned properly/correctly. For example one most common confusion is setting up the Timer_A vector (see MSP430_FAQ#How_to_assign_the_correct_Timer_A_interrupt_vector.3F). If the interrupt vector is not assigned correctly, the device will get reset when the interrupt occurs.

The Flash memory in my application seems to be corrupted, what could be the problem?

The most common reason for flash corruption on MSP430 devices is basically running the CPU in higher frequency while the power supply is experiencing under voltage. For more detailed information, please refer to the MSP430_Flash_Best_Practices wiki page.

When changing the a new device revision the application stops to work, what could be the reason for this?

In most of these cases, the main reason that the application stops to work when using a new/different device revision, is that the application is written in such a way which violate the specification in the datasheet. The specified values/parameters in the datasheet are defined to make sure that all devices from all revisions will work in the ranges, but it doesn't rule out that a specific revision will not work when the device is operated outside the specified parameter values. When this happen with the previous device (application is written to work outside the specified parameters), it might be a good reason that the application will not work with the newer/different revision.

How does the MSP430 retain the I/O port and RTC configurations in LPMx.5?

Going into LPM3.5 and LPM4.5 will basically reset all the peripheral registers configuration upon wake up. However to retain the I/O port and RTC configuration registers, the register values will be latched internally by the corresponding module. These internal settings are locked upon entering the LPMx.5 as the LOCKLPM5 bit of PM5CTL0 register and the LOCKBAK bit of the BACKCTL register are set also. When waking up from the LPMx.5, the I/O and RTC register shall be first configured before clearing the LOCKLPM5 and LOCKBAK bits to prevent an intermediate state in which the default register setting after reset copied into the internal register module setting.

How to achieve the specified power consumption values as in the datasheet?

Test Parameters

All specified values in the datasheet are measured under certain conditions which can influence the result such as:

  • ambient temperature
  • supply voltage
  • for active mode: clock source frequency and code location (flash/RAM)
  • no analog peripheral is active (usually analog peripherals consume very high amount of current, while digital ones are pretty low)
  • etc.

Avoid Floating I/O Pins

All I/O pins are per default set as input after reset. In order to avoid floating input pins consume more current, all unused I/O shall be set as output low with the exception for example if the pin is connected with external pull-up resistor which mean the pin shall be set as output high.

Connection of Unused Pins

Make sure all other unused pins which are not I/O pins comply to the recommended connections which can be found in the Family User's Guide (usually under the chapter dicussing System reset, interrupt, etc. with the name of "Connection of Unused Pins").

Power consumption in RESET state

There is no specification of power/current consumption in the datasheet, and this is not the recommended way to keep the device in lowest power consumption level. The reason is that in reset state, the GPIO pins are in default high impedance floating state which can cause extra power consumption. The recommended way is instead to use a GPIO interrupt which will set the device in LPM4 e.g on falling edge input and re-configure the interrupt to wake up the device on rising edge of the signal.

Operating MSP430 Devices Outside of Specifications

MSP430 microcontrollers are designed, characterized and tested to run within the specifications outlined in the respective datasheets. Operating above recommended maximum values or below recommended minimum values in general could lead to unexpected results, abd operating above Absolute Maximum values or below absolute minimum values in the datasheet can cause physical damage to the MSP430 MCU.

It is true that in some use-cases an MSP430 MCU may operate correctly outside of the specified limits, but performance is not guaranteed and such operations are done at the risk of the user.