Serial connection for MSP430 microcontroller family

The larger MSP430 controllers have two built-in asynchronous serial interfaces (UARTs) and contain a serial bootloader. Unluckily, the pins needed for bootloader application differ from the normal serial port pins. So, making a serial connection that serves for bootloading is a bit difficult and error-prone. See SLAU319 and SLAU265H for Texas Instrument's proposal for a boot loader interface.

Furthermore, it's easy to forget the reset pull-up resistor, as (at least) MSP430F1610 doesn't have one built-in.

Schematic⚓

The following diagram offers an interface with the following properties:

Can operate with built-in bootloader without special adapter cable
Can operate with built-in serial interface (UART) with any baud rate
Feeds back modem status lines from DTR, for automatic hardware handshake
Can optionally support “hardware” handshake in software using RTS/CTS lines
Can support Serial PnP protocol (where RTS is needed) for automatic hardware detection

There are disadvantage using MAX3232 and this solution:

The overall power requirement is not as low as intended for MSP430 applications
Six non-contiguous port pins are used up

Using MAX3232 (instead of MAX232) enables 3 V operation for the level converter and omits the need for some 5↔3 V level conversion.

Schematic (as vector graphic, so you may select text) for most general MSP430 connection. See notes below

Refer to data sheet whether P1.1 and P2.2 are the right port pins for the serial boot loader!

Moreover, some MSP430 (notably those with shared JTAG pins) require inverted TCK polarity. In this case, simply omit R3 and wire TEST directly to RTS.

Function⚓

The bootloader requires connections to TCK, RST, P1.1, and P2.2. The serial data TxD and RxD must be fed inverted though the MAX3232, whereas RTS and DTR don't need inversion, so a simple resistor is sufficient, and speed is out of concern for these two control lines. The RST pin is pulled up with resistor R1.

It was impractical to wire DTR directly to RST, because connection to a serial port will effectively disable the microcontroller, until a terminal program was started for this serial port. Therefore, C1 was added, so a short RESET occurs only:

When connecting the serial cable to an unused serial port
When closing the serial port, e.g. by terminating the terminal program

This is by far much more convenient. The capacitance of C1 is large enough for mspfetcon programming software to run properly.

For regular function, connections to UTxD0 and URxD0 (or similar for UART #1) are required, and the two “hardware” handshake signals are optional. Because most MSP430 have more-than-enough port pins, the easiest solution is to wire a bridge between P1.1 and UTxD0 respective P2.2 and URxD0. The firmware must ensure that P1.1 and P2.2 remain as unused inputs.

For Serial PnP function, detecting a LOW→HIGH transition on host-side RTS line is required. Then, the device answers its ID string using 1200,7,n,1 UART setting. Further operation (especially higher baud rates) is device specific and not covered by the Serial PnP standard.

Modifications and reductions⚓

The MSP430x1xxx devices share SPI, I²C, and UART to one serial interface block. Therefore, keep in mind, when you use USART #0 for UART, you cannot use SPI #0, and the pins SOMI0, SIMO0, and UCLK0 can only be used as regular port pins.

Depending on board layout, it can be better to use USART #1 instead.

As MSP430's UARTs don't have hardware flow control pins (more typical for ARM controllers), it's free to use any port pin for RTS and CTS connections. When no hardware handshake is needed, these connections are not necessary. The two free drivers of MAX3232 can be used for a second serial port.

Only RTS is needed for Serial PnP operation. When no MAX3232 channel is free, simply use a resistor for level conversion (i.e. connect TCK to any port pin), and invert the logic in firmware.